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.
>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. >
