Hi,

I've been digging through the documentation and googling a lot and I
haven't found the exact solution and I'm a bit confused right now and hope
someone can help. What I'm trying to do is to implement multiple iOS
clients using comet + stateful asynch REST in the backend. There are
multiple iOS clients that are listening to messages that are being
broadcast from other clients. Everytime an iOS client does something, then
the action and the corresponding result gets broadcasted to all the other
clients through a LiftActor. This is a pretty common use case, so I'm sure
I'm missing something obvious.

After digging through the documentation and reading about liftActors,
stateful rest, and the asynch REST. I'm assuming that REST with asynch
returns is the best way to do it, but I'm a bit confused on the exact
implementation.

At the simplest level, the code is as follows:

// The url of the app http://someapp.com/cont

object BroadcastServer extends LiftActor with ListenerManager {  // takes
msg and sends it to other clients

object SomeApi extends RestHelper {
 serve{
    case "cont" ::  _ JsonGet _ => {
      S respondAsynch {
        BroadcastServer ! "some String"  

        println("Session information:" + S.session.toString)

        Full(OkResponse())

        // need to send back information continuously, how do you do this?
      }
    }

I'm a bit confused on the following items:
1. How do I register the iOS client so that the BroadcastServer LiftActor
will push back the client message to the iOS client?  
   a. What's the url that I need to poll in order to get the response?
http://someapp.com/cont only returns the 200 response and doesn't seem to
register the client to the LiftActor
   b. The iOS client has the sessionid, but that doesn't seem to be
sufficient. There seems to be a auto generated GUID that corresponds to the
LiftActor. Does the iOS have to implement this as well? It seems like the
web client implements them seamlessly with CometActors. How does this work?
   c. I've read Diego's post
http://blog.fmpwizard.com/lift-comet-and-a-rest-api It's good that the
cells are updating via different web clients via comeactors, but how do you
implement it so that the iOS client receives the updates and how does the
registration happen?
  d. What parameters does the iOS client have to have to autogenerate the
url that it's constantly polling?
2. When I get into the code block respondAsynch. It loses the session and
context. Is there a way to maintain sessions while doing asynch processing
or is this not possible?  
3. If I cannot maintain sessions during asynch processing, how do I
maintain a session for a *single* iOS client while providing a url
to continuously return back msgs from the LiftActor?
4. The asynch rest api returns a response code immediately
(NoContentResponse of OkResponse) and then asynchronously returns a
response. How do I make it so the resthelper asynch function registers
itself to the LiftActor so that it will constantly get the callback from
the LiftActor?

I've been reading a lot of examples that have a bit of CometActor, a bit of
Rest API and a bit of asynch Rest api implementation. It would be great if
someone can point me to either a github example of this specifically with
the iOS client implementation, a blog article where it explains the exact
url in which the iOS has to generate, and any/all of the 1-4 questions I
have above. I'm having a hard time synthesizing all the examples into what
I want. Thanks for your help in advance.

Cheers,

Zao

Hi,

I'll try to answer at least some of your questions:

I think I have only seen one other question like this, so I don;t
think this would be something obvious. That being said, I have been
thinking for a while that a push notification would do just what you
are trying to do.

Yes, I would use rest async, but the idea may be a bit different.

REST Asycn means that you do a request (call
http://app/host.com/notifications), the client will have something
like a 70 second timeout (this number is totally made up, you may want
to adjust the value), and Lift should respond with some new data
(something some other client sent), within those 70 seconds. Now,
using async, Lift will put your request in continuation (assuming you
are using jetty > version 7 or tomcat ( I think version 7 has
continuation). this basically means that you are not holding that one
thread locked until you get an answer. So this helps you scala better,
as fewer threads can handle more http /iOS clients).

Now, your iOS client will have to implement a good chuck of logic,
that most of us get for fre when we develop a web app using regular
comet.

1- If you don;t get an answer in 70 seconds, you timeout the request,
and make a new one
2- when you do get some data, start a new http request, to ask for more data
2.a - I don;t know if iOS allows this, but ideally you would process
the just received data on a different thread, while there is a new
http request)
3- Make sure you have only one http connection per cell phone.
4- you may want to send some kind of sequence id with your http
request, so that Lift will know how much data you already have on your
client

Let me explain this one

1- my cell sends a new update to your lift app, let's call this the seq 1
2- the 3 other iOS clients have been sending http request to Lift with
seq 0, because nobody had sent any updates yet
3- as soon as my cell data made it to the Lift app, all other 3
iphones get the new data, including the seq id  1
4- when the other 3 iphones send new requests, they need to include
the new seq id 1, so that Lift will not send the same data to those
iphones
5- repeat

So, there isn;t really an iPhone registering with a lift actor, you
can have one one LiftActor that knows how to retrive the updates, and
will just see which seq id the iPhone saw last, and will return a List
of notifications greater than that ID

There is no registering

you can have any url, in your case, it could be
http://someapp.com/cont
but in your async call don;t return an answer, unless you have one (or
your reached the 70 second timeout)

so, with my idea, there is no need for the session info, actually, it
would be better if you go the  stateless path (but doing a login on
each request may be too much overhead, I guess you will have to see,
but if you can, try to go stateless, so there are less resources being
used on the Lift server) I'm only saying this for a RESt service, for
a web app, you most of the time want stateful

I'm glad you read that post :)
I think I answered this a few paragraphs abode.

The url is always the same, just keep incrementing the seq, ah, and
think of what to do when your lift app has been running for a months,
you don;t want to give a new iPhone client 2000 notifications, just
because it was restarted or something. (so, you will not always start
from seq 0.

if you put together a sample app that shows this, I can play around
and see what I find, you may need to copy the info you need into a
RequestVar

You will not need this.

I'll skip this one because I'm not sure right now.

You are going where very few people have gone before, or at least they
don't talk about it, so thanks for the questions and I hope I have
been helpful, if we get it working, I'll try to blog about it and
include a working example (it would really help me if you can post a
sample with the rest part of it (even the skeleton).

Thanks

  Diego

--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com