incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <vdic...@apache.org>
Subject Re: API 2.0 update and design questions
Date Wed, 26 Aug 2009 16:19:14 GMT
> @Daniel - maybe Vassil can help you there. What exactly was your problem?

@Daniel- I realize now we intended to make the message parser
pluggable, but then there was always something which seemed more
important. I think this is the right time to get back to this issue.
The problem here is that many of the higher-level parser combinators
use common low-level combinators, i.e. email address, identifier
characters (for usernames, pool names, etc.). In order to reuse these,
it's a good idea to separate and document the low-level parser
combinators we can rely on (like an API).

@Ethan- Regarding "streaming", we already have long-polling that's
built in Lift with the Comet actors. Using Atom is OK, but it's
certainly serves a different purpose, since it's not real-time. For
reverse HTTP you'll have to wait a while before we can even discuss
it, since it's just in the specification draft phase. PubSubHubBub is
also quite new, and I don't see what more it offers to what we already
have with the comet actors. All in all, it's a bit confusing for me to
see all those different protocols and technologies together- they
serve slightly different purposes, and are in varying stages of
maturity. So, again- what is the use case we want that we don't
already have?

I'll be more than happy to help with whatever I've learned about
Scala- and Lift.

Vassil

Mime
View raw message