Hi all, This email is serving two purposes. One is to ping the list to let you all know that I'm making more updates to the API 2.0 design page on the cwiki at http://cwiki.apache.org/confluence/display/ESME/REST+API+2.0+-+Design It now includes reference to the need for real streaming interfaces to parts of the API.
The second purpose is to surface some of the questions that we're facing at the moment. Questions are outlined below. I do first want to note that this API is strictly vapor-ware/-design at the moment, so it's quite possible that the next step for me here is to learn Scala and Lift. If anyone else with a few more Scala chops is interested in starting work on this with me immediately though, then by all means let's get started. :-) In the meantime, there are open items that I think need to be resolved to move ahead. I'm listing them here along with my *opinion* to hopefully facilitate some discussion. 1. REST - I'm thinking of just dropping "REST" from the name of the API. It should still be designed with RESTful principles in mind where appropriate but it's probably time we move past this issue as a group and dropping the term from the API title might be a good step in this direction. 2. Authorization - I think the current authorization scheme using tokens is insecure over non-encrypted connections since the token is passed in the clear. It also uses sessions, which are nice in some contexts and not in others. Food for thought. I'm not changing anything here at the moment, but it's on my mind and I don't think it's currently satisfactory. At the risk of getting my head bitten off, my thought process here still tends towards the message-signing half of the OAuth spec to guide our authorization approach, but I'm not particularly devoted to that idea if there are better ones, especially since OAuth is not proven on non-native-HTTP protocols (see streaming below). 3. Streaming - I think there is a major question around how we stream the parts of the API that require streaming (messages specifically). Does ESME do this currently? My research seems to indicate that AMQP is probably the most performant and interoperable way to accomplish streaming (though JMS should be reasonable as well, if not as inter-operable in non-enterprise environments). I also seem to see that Lift has built-in AMQP support. Does ESME already support AMQP pub/sub? If so, then I think we can probably just document this support and call it a day. Other options include XMPP, and various streaming and pub/sub approaches over HTTP. 4. HTTP fallback for clients that do not support streaming - For clients that don't interoperate with our chosen streaming mechanism (whatever that may be), will we offer one or more HTTP-based fallbacks? The simplest fallback would be a poll-able Atom feed. I think we all agree this is not good, but it could work. More advanced fallbacks might be long-polling, Reverse HTTP, or PubSubHubBub. Please see the wiki page for links. I think we need to offer some HTTP-based capability that is widely-compatible for those clients that don't have access to network resources below the HTTP level, but I'd like to know what you think and if you have a preference. That's probably enough for now. I'd really like to know what you all think and how you'd like me to proceed if you have a preference. Thanks, Ethan
