It seems like a pretty good approach to me. One thing to watch out for is that things can vanish from the memcache (due to memory pressure). Don't assume it's going to be a reliable storage mechanism! If you're OK with possibly losing events, then it's OK, but if you require all events to for sure be delivered, you might want to consider using the datastore instead.
On Nov 5, 11:44 am, slmnhq <[EMAIL PROTECTED]> wrote: > Hi, > > I'm starting to build an interactive application where an event (eg: > mouse click) in one user's browser needs to trigger another event (eg: > show a message) in another user's browser. Sometimes data (eg: chat > messages) will be passed from one session to another. > > The way I was going to implement this was was to have the event > producer make a json-rpc call to the GAE application. The application > would store the message in a "queue" which is just a list of messages > in memcache. The event consumer will periodically poll (via json-rpc) > to get messages intended for it. There will be one message queue for > each session. > > Each browser session will have a session id - I have not figured out > how and when to generate this id. > > This is a somewhat naive approach and I was curious if there are > issues that I might run into. > > Thanks, > Salman --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
