On Wed, Nov 4, 2009 at 8:09 AM, Markus Kohler <[email protected]>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 > <[email protected]>wrote: > > > On Wed, Nov 4, 2009 at 2:58 AM, Markus Kohler <[email protected] > > >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 <[email protected]> > > 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
