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 18:14:10 GMT
And not to put a fine enough point on this discussion, but Novell announced
Pulse today... it's a Lift-base enterprise front-end to Google Wave.  See:
http://twitter.com/djspiewak/statuses/5424470339
http://twitter.com/djspiewak/statuses/5424501524
http://twitter.com/djspiewak/statuses/5424817863

So, if Lift and Comet are good and scalable enough for Novell to adopt for a
key project, what could possibly argue against using the technology in
ESME?  To further amplify on this, there was not a single Comet-related
ticket or issue that Novell identified in Lift as part of this project, so
I'm pretty sure that any hand-waving about scalability is pure, untested BS.



On Wed, Nov 4, 2009 at 6:35 AM, 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