incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <feeder.of.the.be...@gmail.com>
Subject Re: Patch submitted, working towards API design
Date Wed, 04 Nov 2009 17:14:02 GMT
On Wed, Nov 4, 2009 at 8:09 AM, Markus Kohler <markus.kohler@gmail.com>wrote:

> 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


It already is implemented.


> and can be scaled to a certain extent


Yeah, in fact you did question this.  This was pretty much the crux of your
argument as far as I read it.


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


Sorry you're unclear on the vision.  ESME is not the flavor of the day
REST.  It's something different: a human consumable event engine.  Yeah, now
Google Wave has a bunch of pieces that are not dissimilar from ESME (or vice
versa) in terms of blending synchronous and asynchronous conversations.
ESME is pushing boundaries rather than recycling a current paradigm.


> , for this kind
> of application,it's not chat isn't it?
>

Yes, it is chat.  It's immediate feedback.


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

You're wrong.  Continuing to make this assertion does not serve anyone's
goals.


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

Beginning the design from an event basis and then deciding which APIs more
accurately reflect "static" RESTful content is the approach I've
recommended.


> It's not black and white after all.
>

No, it's not, but taking your cues from Vassil about direction rather than
disagreeing based on technology that you do not understand does not help.


>
> 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
>
>
He's addressing a different problem.  First, he's not addressing the
immediate feedback problem.  If users have to wait 30 seconds or a minute
for an update, there's no conversation.  Second, keeping delta timeline
queues since a certain time is expensive in terms of time and space.  While
the current ESME implementation could handle it, it does not scale.
Fielding is addressing a single queue problem (what has changed globally)
rather than a what has changed for a given user since a certain time.


> It's also not clear to me why it has to be COMET and why this cannot be
> abstracted away.


If you don't understand this then you should not be participating in this
conversation.

David


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



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