esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: API 2.0 update and design questions
Date Thu, 27 Aug 2009 13:53:30 GMT
On Wed, Aug 26, 2009 at 2:25 PM, Vassil Dichev <> wrote:
> I see, those technologies you were listing were just possible options,
> and not a list of things we should implement.
> Lift does offer integration with AMQP and we were discussing on the
> ESME mailing list about using that. I also think there might be value
> in Atom since it offers the easiest way for a client to check which
> messages are new (couple of lines of Scala code). As for real-time
> updates over HTTP, the way to go is to use an abstraction like the
> Lift CometActor, so whenever there's a better technology than long
> polling out there, the CometActor can be reimplemented in it and no
> changes in ESME are necessary whatsoever. In fact, if memory serves me
> right, David has mentioned that Comet would be reimplemented in
> Reverse HTTP when it matures a bit.

 That's very interesting and could be either good or bad depending on the
situation. If we are building an integrated web application based on Lift
(which we are in the case of ESME) then I really like the auto-upgrade
capability delivered with the CometActor. If we are building an API (which
we are also doing), then I would think we definitely *don't* want the API to
auto-upgrade like you describe. Something like switching from the current
long-polling to reverse-http would break all existing clients and would
require something like a new version of the API and a period where the two
APIs ran in parallel. Would that be possible using the Lift CometActor?


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