It's hard for me to see Comet as RESTful. I would consider it a new use of HTTP that demands a new way of thinking. You'd probably want to use a lower level API than Restlet, so you can fully leverage asynchronicity.
Have you considered repeat rapid polling instead of using Comet? On 04/21/2010 05:12 PM, Marc Larue wrote: > Ok, I realize you are all talking mostly from a B2B perspective. I'm > developing a realtime comet system for multiplayer games (Ajax, JSON, > Rupy); so my perspective is a little different. > > Right now I'm trying to figure out how to make my XSS messaging system as > cheaply scalable as possible; specifically how to transfer users from the > lobby to a game room on another server and how to build a generic protocol > for this. > > Comet is hard to build without session state since you communicate on two > sockets with every client and in my case the session is used to tie these > together. > > Anyhow I have a stateful client, now I just need to figure out the best > way to synchronize clients and I think you are right; CPU goes before > bandwidth in my case too. > > Maybe a "fullstate" monopacket protocol? > > Cheers, > > /marc > > On Wed, 21 Apr 2010, Tal Liron wrote: > >> REST services are only as chatty as however you define your resources. >> >> I've seen many REST architectures suffering from a failure of imagination: >> the architects assume that "resource" has to have a one-to-one mapping with >> "database row" or other concrete entity, when in fact there is not such >> requirement. Resources should be use-specific, logical to the application, >> not to its underlying implenetation. It's possible to devise resources that >> are logical associations of various complex business logic, and do as much >> as you do with a SOAP request. >> >> Also, I don't think REST has to be stateless. HTTP headers are used >> specifically for passing state, and cookies are full-blown shared state. >> >> Why not implement sessions via cookies? Of course, there are potential >> scalability issues with shared state and sessions, but these are general >> problems and not specifically addressed by REST. >> >> My advice: >> >> 1) Use cookies, they are good, but -- >> 2) Don't maintain heavy, persistent sessions on the server. Create a >> lightweight scheme that lets you quickly do a secure operation per user. >> 3) Think very careful about what you consider a "resource", and try to bunch >> as much functionality as you can into one request. This will also help you >> in minimizing the costs of session access. >> >> -Tal >> >> On Wed, Apr 21, 2010 at 11:48 AM, Stephen Groucutt< >> stephen.grouc...@gmail.com> wrote: >> >>> REST services are definitely chatty, especially when compared to SOAP >>> webservices that might perform N operations in one shot. >>> >>> To me, the chattiness goes hand-in-hand with the HATEOAS concept, where a >>> client picks its way through multiple server resources via links that are >>> present in the representations, to perform some task. Being bad on >>> bandwidth seems to me to be an inherent part of the architectural style of >>> REST. >>> >>> So, I think this just means that bandwidth has to be a consideration when >>> you are deciding what architectural style fits your system's domain. >>> >>> >>> On Wed, Apr 21, 2010 at 12:58 PM, Marc Larue<m...@rupy.se> wrote: >>> >>>> I'm just chiming in to this, so this means with REST you have to send the >>>> whole state back and fourth between client and server on every >>>> request/response. So what does REST say about bandwidth, it's not a >>>> problem? >>>> >>>> Cheers, >>>> >>>> /marc >>>> >>>> On Wed, 21 Apr 2010, Thierry Boileau wrote: >>>> >>>>> Hi Matt, >>>>> >>>>> from what I see, the authenticator just have to check the presence of >>>> the user principals (set by GAE) in the authenticate(Request, Response): >>>>> !request.getClientInfo().getPrincipals().get(0). >>>>> >>>>> You can provide a verifier in order to check that the application knows >>>> the user identified by the principal name (actually the user's mail) and >>>> set >>>> the clientInfo#user. >>>>> Best regards, >>>>> Thierry Boileau >>>>> >>>>> ------------------------------------------------------ >>>>> >>>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591291 >>>> ------------------------------------------------------ >>>> >>>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591738 >>>> >>> >> ------------------------------------------------------ >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591936 > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2591952 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2592758
