incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <>
Subject Re: Patch submitted, working towards API design
Date Wed, 04 Nov 2009 14:35:49 GMT
On Wed, Nov 4, 2009 at 2:58 AM, Markus Kohler <>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 ( ), 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

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:
> ,
> which make sense to me, at least at a first glance.
> <
> >
> Regards,
> Markus
> On Wed, Nov 4, 2009 at 10:05 AM, Vassil Dichev <> 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
Beginning Scala
Follow me:
Surf the harmonics

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message