Re: [ogpx] event queues for fun and profit

[Christian Scholz <[e-mail]>]

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