> @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
