incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Kohler <markus.koh...@gmail.com>
Subject Re: Patch submitted, working towards API design
Date Wed, 04 Nov 2009 16:09:02 GMT
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
<feeder.of.the.bears@gmail.com>wrote:

> On Wed, Nov 4, 2009 at 2:58 AM, Markus Kohler <markus.kohler@gmail.com
> >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 <vdichev@apache.org>
> 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
>

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