[ogpx] event queues for fun and profit

[Infinity Linden <[e-mail]>]

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