Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of feeder.of.the.bears@gmail.com
 designates 209.85.217.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=KqyCncbDwVamLBjWlif9I9u1pdPmx8ejOJ5pCD3gBzMuZF+rzf/YzciiYLzP2IdSZN
         f6Jm6oBCGRLO7Q2bLP6RVOv5S+ErDf4QNXOAQKL7YMhlf0CJQLbW4mI/6PRuXqBZtCOl
         omnasPWpFuUbIwidJEdVlRmi/azFKvBNGgRhs=
MIME-Version: 1.0
In-Reply-To: <771905290911040809n24ad6a6ey9a00c1d819dfbb15@mail.gmail.com>
References: <68f4a0e80910251728te9c1248j10f1aa99c9f7cd2e@mail.gmail.com>
	 <fa2d9f450910270041r7abe9bdbq1cd106131d6ae977@mail.gmail.com>
	 <68f4a0e80910270917r408588fbva0f47e73125afa4d@mail.gmail.com>
	 <771905290911031021n6aa33b53q1532c04601fd6433@mail.gmail.com>
	 <c7fc82820911032328t63ac734cx97616507b902d2ef@mail.gmail.com>
	 <771905290911040043p61039939r99b3d1a602a92e8f@mail.gmail.com>
	 <c7fc82820911040105t4da6857i9b98c01fdc0db632@mail.gmail.com>
	 <771905290911040158v539c016em1221acf54bbb5509@mail.gmail.com>
	 <cdbebedf0911040635y76afdeb5yd24640026b613381@mail.gmail.com>
	 <771905290911040809n24ad6a6ey9a00c1d819dfbb15@mail.gmail.com>
Date: Wed, 4 Nov 2009 09:14:02 -0800
Message-ID: <cdbebedf0911040914w53014c35qad318a9bda4eb6b6@mail.gmail.com>
Subject: Re: Patch submitted, working towards API design
From: David Pollak <feeder.of.the.bears@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016368324b2c55c5f04778ebc94

--0016368324b2c55c5f04778ebc94
Content-Type: text/plain; charset=UTF-8

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

--0016368324b2c55c5f04778ebc94--