Hi all, I just tried to give some feedback to the current state of the REST Api document, assuming that there was a consensus, that there's a need to for it. I'm not sure anymore, whether that's really the case.
Just to make clear. I never questioned that a COMET based ESME can be implemented and can be scaled to a certain extent, nor did I question any competence here. I'm even not surprised that Lift/the Actor framework can handle the differences between app servers automatically. I just said it's harder (testing also requiring more effort), and that it's not clear to *me* whether this additional effort is worth it, for this kind of application,it's not chat isn't it? Maybe I didn't express it clearly but I also think that for the number of users (not millions I guess) that an ESME server might not need to handle it might even work without too much effort. In any case I believe that *some* Rest is still needed, if the web application should support bookmarking and indexing by a search engine's web crawler. It's not black and white after all. Regarding REST principles not compatible with an application like ESME, Fielding itself doesn't seem to believe that: http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons It's also not clear to me why it has to be COMET and why this cannot be abstracted away. I think a client library for a specific programming language could be written, that would abstract a way from where "Events" would come, e.g. it would be hided whether it's COMET,polling ,XMPP or whatever. Regards, Markus On Wed, Nov 4, 2009 at 3:35 PM, David Pollak <[email protected]>wrote: > On Wed, Nov 4, 2009 at 2:58 AM, Markus Kohler <[email protected] > >wrote: > > > Hi Vassil, > > Sorry, it was not clear to me that real time is a key differentiator for > > ESME, and it's already build around it. > > I'm just saying, that you shouldn't expect that this scales easily to > > thousands of users( maybe it doesn't need to) without special Web > container > > support. That might not even be a problem AFAIK besides Jetty, Tomcat has > > it > > and Glassfish 3 probably has it as well. > > > > Lift automatically detects that it's running in a Jetty and uses Jetty > continuations to support long polling without consuming thread resources. > That's the whole premise behind CometActors. As other popular containers > and/or standards appear that support continuations without hardcoding > interfaces, Lift will automatically support those as well. So, you're > scalability argument has no grounds in technical realities. > > Further, if you take a look at the Lift committer team ( > http://www.liftweb.net/team.html ), you might recognize names and faces > from > a more popular micromessaging service that transitioned to using Scala for > scalability. Hmmm.... maybe there's something about the abstractions that > Scala has to offer that allow for the building of scalable micromessaging > systems. > > If you go back in the ESME archives, you'll see another thread similar to > this one. > > I am absolutely opposed to trying to force the event based nature of ESME > (it's an event manipulation system that's more usable by real humans than > the likes of AMQP) into the limitations of REST and the REST concept. REST > is the antithesis of flowing messages. It's modeled on static. ESME is > modeled on dynamic. I appreciate the efforts and thought that Ethan has > put > into the APIs, but at the end of the day, things that treat REST and the > primary design goal will be flushed from ESME in favor of building API > abstractions that favor events over a static model. > > > > > > > From the REST API point of view I don't think there's much to do, other > > than > > appending something to the URL that indicates that connection needs to be > > kept open for COMET style communication. > > > > One point that the REST API probably needs to support is a way for not > > always connected clients to "sync" only new messages. > > > > Googles gdata does this with etags: > > > > > http://code.google.com/apis/gdata/docs/2.0/reference.html#ResourceVersioning > > , > > which make sense to me, at least at a first glance. > > < > > > http://code.google.com/apis/gdata/docs/2.0/reference.html#ResourceVersioning > > > > > > > > > Regards, > > Markus > > > > On Wed, Nov 4, 2009 at 10:05 AM, Vassil Dichev <[email protected]> > wrote: > > > > > > I understand that it would be nice to show Scala advantages, but if > > real > > > > time messages, such as in a chat are not the first goal, I would > rather > > > > concentrate on supporting pagination. Just my humble opinion of > course. > > > > > > I've also said before that pagination is great to have, but "real time > > > messages, such as in a chat" are not a goal, they exist in ESME right > > > now, and ESME design revolves around that. > > > > > > > Oh and BTW properly (performance) testing Comet based applications > > turned > > > > out to be an up hill battle. I'm still convinced that I can deliver > > > > something, but it will take more time. The issue is that "standard" > > load > > > > testing tools such as Loadrunner or JMeter are based on the > assumption > > > that > > > > you just want to replay short HTTP requests. That approach doesn't > > really > > > > work with Comet based apps because they hold a connection open. > > > > > > True. That's one excuse we don't have that many tests. I'd like to > > > think it's the major one, but unfortunately it's not. > > > > > > > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics >
