And not to put a fine enough point on this discussion, but Novell announced Pulse today... it's a Lift-base enterprise front-end to Google Wave. See: http://twitter.com/djspiewak/statuses/5424470339 http://twitter.com/djspiewak/statuses/5424501524 http://twitter.com/djspiewak/statuses/5424817863
So, if Lift and Comet are good and scalable enough for Novell to adopt for a key project, what could possibly argue against using the technology in ESME? To further amplify on this, there was not a single Comet-related ticket or issue that Novell identified in Lift as part of this project, so I'm pretty sure that any hand-waving about scalability is pure, untested BS. On Wed, Nov 4, 2009 at 6:35 AM, 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 > -- 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
