Re: [ogpx] event queues for fun and profit

[Infinity Linden <[e-mail]>]

cool. learning more about wave has been on my todo list for at least a
few days. using XMPP to carry OGP application PDUs may be a topic for
the future, it's totally in scope for MMOX. the use case is in scope
here.

it might be worth it to make a few comments about OGP, HTTP and XMPP.
OGP was originally envisioned as an application layer protocol. That
is... the transport that carries application to application messages
is not as important as the application messages themselves. Though OGP
is currently only defined with HTTP as a transport, we wanted to make
it generic enough so that in the future if it made sense to carry OGP
application layer messages over XMPP, SIP, SMTP or even carrier
pigeon, it would not be terribly hard to modify the existing
specifications.

that being said... we're currently focused on OGP over HTTP
exclusively. we (linden) did that 'cause a) we have limited resources
and b) at the current time the tool chain for HTTP seems more mature
than the tool chain for XMPP. that will eventually change, i'm sure.
but for right now, we're pretty focused on OGP/{R}HTTP(S).

but there are very clearly some use cases (like the event queue) that
XMPP (or an XMPP like solution) would be more appropriate. it just
seems that at the current time, it's easier to implement an event
queue on HTTP than it is to build a robust XMPP tool chain.

this will change, and i look forward to the day that i'm forced to eat
those words cause it will mean it's at least as easy to deliver a
compelling service over XMPP as it is to deliver it over HTTP. but
right now... while we're waiting for the world to change, we're moving
forward with OGP/HTTP. but it's good to see wave getting deployed
'cause it means we're closer to the future.

-cheers
-meadhbh

On Tue, Jun 2, 2009 at 3:49 PM, Christian Scholz <[e-mail]> wrote:
> Hi!
>
> Just a short thing: Did you look at http://waveprotocol.org?
> It's XMPP based and somehow a very much related use case. I haven't looked
> that close into it myself but it at least looks very promising. Moreover
> it's coming from Google and thus might get some traction and community
> around it.
>
> (but maybe this is more something for discussion on MMOX)
>
> -- Christian
>
> Infinity Linden schrieb:
>>
>> so... event queues...
>>
>> to recap.. you can find info re: event queues in the OGP : Base
>> document at http://tools.ietf.org/html/draft-lentczner-ogp-base-00 .
>> an event queue is a service used by an HTTP client to get unsolicited
>> event notifications from a server. After logging into the agent
>> domain, one of the caps you should request is the event queue. You
>> then listen on the event queue for messages, process the server to
>> client messages and send the response back to the server via the event
>> queue cap.
>>
>> and here are some issues open for discussion...
>>
>> * how many event queues do we need? are we only going to have one
>> event queue from the client to the agent domain, and then have all
>> other services forward messages they want to send to the client to the
>> AD? or do we say... "one event queue per client : host pair"? or do we
>> further define the concept of a "service" as a collection of related
>> caps, including an event queue?
>>
>> * asynchronicity - the event queue as it is defined currently defines
>> synchronous messages. the benefit here is that synchronicity is
>> "simple" in terms of state. the drawback is that the client
>> application MUST respond to the current message BEFORE it can request
>> the next one in the queue. an asynchronous message queue may require
>> application layer protocol equivalents of re-transmitting, windowing
>> and message time outs that would complicate the server -> client
>> interaction. if we're worried that one synchronous message that took a
>> long time to process could hold up the entire queue, we might want to
>> make the implementation of that message have the pattern of... "create
>> a capability on the client representing the client's response to a
>> message. i (the server) will poll it and see if it's done."
>> honestly... all the solutions to this problem have warts.
>>
>> * message count - should we let multiple server -> client messages
>> flow in a single request to the event queue cap?
>>
>> * RHTTP - right now we're looking at the event queue being implemented
>> as a long poll over HTTP. ultimately, a technology like RHTTP would
>> reduce server overhead. (
>> http://tools.ietf.org/html/draft-lentczner-rhttp-00 ) i think the
>> discussion around this point is... let's not do anything with the
>> event queue that makes it harder to implement RHTTP later. Or
>> websockets or bosch or beyaux for that matter.
>>
>> * capabilities on the client - readers familiar with COMET or AJAX
>> will remember that simply defining an event queue is just half the
>> battle; rich clients are likely to have multiple objects that will
>> receive messages along the queue, so you have to have some way to
>> demultiplex messages. one way to do this is to model capabilities on
>> the client as endpoints for messages flowing across the event queue.
>> an advantage of this approach might be the ability for the server to
>> pass off a client capability to another server that will complete a
>> service request. hmm... more on this later... this probably warrants
>> it's own conversation thread and involves the concept of RHTTP URLs
>>
>> * externally identifying event queues - so imagine you're a client.
>> you authenticate yourself to the agent domain and ask for caps for a
>> couple services. we'll call them "search:group",
>> "search:group:event_queue", "group:im" and "group:im:event_queue". the
>> protocol makes no assumptions as to whether the protocol endpoint that
>> implements the "search:group:event_queue" and "group:im:event_queue"
>> caps are the same URL or if they're different URLs. it would be
>> advantageous for the client to be able to, upon seeing that both caps
>> are implemented on the same URL NOT open a second connection to the
>> url. so the question is.. representing event_queues as URLs is not a
>> problem, right?
>>
>> i'm sure there's more we could add to this, but this is just a bit to
>> get the conversation started.
>>
>> -sincerely
>> -meadhbh / infinity
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>
>
> --
> COM.lounge GmbH
> http://comlounge.net
> Hanbrucher Strasse 33, 52064 Aachen
> Amtsgericht Aachen HRB 15170
> Geschäftsführer: Dr. Ben Scheffler, Christian Scholz
>
> email: [e-mail]
> fon: [phone]
> fax: [phone]
>
> personal email: [e-mail]
> personal blog: http://mrtopf.de/blog
> personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net
>
>