I have a question whether it makes sense to use Comet's partialUpdate
or rather plain Ajax in the following situation:
On our site, the user can enter some piece of information which is
then ajax send to the server. Currently the call immediately returns,
which is desired.
On the server side some processing is done with that data in a
separate thread and when done the data is sent to a Comet Actor.
This actor then sends the data to the requesting user, and only to
him. There is no need to send the data to other browsers.
I choose Comet Actor for this because it takes a few seconds to
process the data, which I wanted to be done in a different thread. The
user can continue to work and when the processing is complete the data
appears in his browser.
Is that a use case for Comet (because it's only pushed to the same
browser it came from) or should I resort to plain Ajax? What's the
processing overhead for comet because it's send to every comet
listener?
If I should do that with plain Ajax, can I still process the request
in a different thread and answer the ajax call when complete?
Having a CometActor per page is the right approach... and having a randomly
named comet actor per page is better so that you'll have a different
instance per page.
I don't understand how CometListener works into the design. Why not just
send the message directly from the Ajax handler to the CometActor
associated with the page that the Ajax request came from?
On Sat, Apr 28, 2012 at 5:53 AM, Torsten Uhlmann <T.Uhlm...@agynamix.de>wrote:
> I have a question whether it makes sense to use Comet's partialUpdate
> or rather plain Ajax in the following situation:
> On our site, the user can enter some piece of information which is
> then ajax send to the server. Currently the call immediately returns,
> which is desired.
> On the server side some processing is done with that data in a
> separate thread and when done the data is sent to a Comet Actor.
> This actor then sends the data to the requesting user, and only to
> him. There is no need to send the data to other browsers.
> I choose Comet Actor for this because it takes a few seconds to
> process the data, which I wanted to be done in a different thread. The
> user can continue to work and when the processing is complete the data
> appears in his browser.
> Is that a use case for Comet (because it's only pushed to the same
> browser it came from) or should I resort to plain Ajax? What's the
> processing overhead for comet because it's send to every comet
> listener?
> If I should do that with plain Ajax, can I still process the request
> in a different thread and answer the ajax call when complete?
Thanks heaps for your response, and thanks for the hint with the randomly named CometActor per page.
Now, how do I sent a message to the CometActor associated with the page the request came from?
We currently have something like this:
class NotificationsActor extends CometListener
That thing registers with a NotificationServer to whom I sent the messages. How would I send the message to the Actor directly, do I just keep a reference in a RequestVar?
> Having a CometActor per page is the right approach... and having a randomly named comet actor per page is better so that you'll have a different instance per page.
> I don't understand how CometListener works into the design. Why not just send the message directly from the Ajax handler to the CometActor associated with the page that the Ajax request came from?
> On Sat, Apr 28, 2012 at 5:53 AM, Torsten Uhlmann <T.Uhlm...@agynamix.de> wrote:
> Hi all,
> I have a question whether it makes sense to use Comet's partialUpdate
> or rather plain Ajax in the following situation:
> On our site, the user can enter some piece of information which is
> then ajax send to the server. Currently the call immediately returns,
> which is desired.
> On the server side some processing is done with that data in a
> separate thread and when done the data is sent to a Comet Actor.
> This actor then sends the data to the requesting user, and only to
> him. There is no need to send the data to other browsers.
> I choose Comet Actor for this because it takes a few seconds to
> process the data, which I wanted to be done in a different thread. The
> user can continue to work and when the processing is complete the data
> appears in his browser.
> Is that a use case for Comet (because it's only pushed to the same
> browser it came from) or should I resort to plain Ajax? What's the
> processing overhead for comet because it's send to every comet
> listener?
> If I should do that with plain Ajax, can I still process the request
> in a different thread and answer the ajax call when complete?
> Thanks heaps for your response, and thanks for the hint with the randomly named CometActor per page.
> Now, how do I sent a message to the CometActor associated with the page the request came from?
> We currently have something like this:
> class NotificationsActor extends CometListener
> That thing registers with a NotificationServer to whom I sent the messages. How would I send the message to the Actor directly, do I just keep a reference in a RequestVar?
> > Having a CometActor per page is the right approach... and having a randomly named comet actor per page is better so that you'll have a different instance per page.
> > I don't understand how CometListener works into the design. Why not just send the message directly from the Ajax handler to the CometActor associated with the page that the Ajax request came from?
> > On Sat, Apr 28, 2012 at 5:53 AM, Torsten Uhlmann <T.Uhlm...@agynamix.de> wrote:
> > Hi all,
> > I have a question whether it makes sense to use Comet's partialUpdate
> > or rather plain Ajax in the following situation:
> > On our site, the user can enter some piece of information which is
> > then ajax send to the server. Currently the call immediately returns,
> > which is desired.
> > On the server side some processing is done with that data in a
> > separate thread and when done the data is sent to a Comet Actor.
> > This actor then sends the data to the requesting user, and only to
> > him. There is no need to send the data to other browsers.
> > I choose Comet Actor for this because it takes a few seconds to
> > process the data, which I wanted to be done in a different thread. The
> > user can continue to work and when the processing is complete the data
> > appears in his browser.
> > Is that a use case for Comet (because it's only pushed to the same
> > browser it came from) or should I resort to plain Ajax? What's the
> > processing overhead for comet because it's send to every comet
> > listener?
> > If I should do that with plain Ajax, can I still process the request
> > in a different thread and answer the ajax call when complete?
> > > On Sat, Apr 28, 2012 at 5:53 AM, Torsten Uhlmann <
T.Uhlm...@agynamix.de> wrote:
> > > Hi all,
> > > I have a question whether it makes sense to use Comet's partialUpdate
> > > or rather plain Ajax in the following situation:
> > > On our site, the user can enter some piece of information which is
> > > then ajax send to the server. Currently the call immediately returns,
> > > which is desired.
> > > On the server side some processing is done with that data in a
> > > separate thread and when done the data is sent to a Comet Actor.
> > > This actor then sends the data to the requesting user, and only to
> > > him. There is no need to send the data to other browsers.
> > > I choose Comet Actor for this because it takes a few seconds to
> > > process the data, which I wanted to be done in a different thread. The
> > > user can continue to work and when the processing is complete the data
> > > appears in his browser.
> > > Is that a use case for Comet (because it's only pushed to the same
> > > browser it came from) or should I resort to plain Ajax? What's the
> > > processing overhead for comet because it's send to every comet
> > > listener?
> > > If I should do that with plain Ajax, can I still process the request
> > > in a different thread and answer the ajax call when complete?
