Subject: [ogpx] event queues for fun and profit

From: Infinity Linden <[email-masked]>
Date: Tue, 2 Jun 2009 15:22:24 -0700

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

---

From: Christian Scholz <[email-masked]>
Date: Wed, 03 Jun 2009 00:49:26 +0200

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:
> _______________________________________________
> ogpx mailing list
> [email-masked]
> 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: [email-masked]
fon: +49-241-4007300
fax: +49-241-97900850

personal email: [email-masked]
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net

---

From: Infinity Linden <[email-masked]>
Date: Tue, 2 Jun 2009 16:09:46 -0700

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 <[email-masked]> wrote:
> 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.
>

---

From: Suzy Deffeyes <[email-masked]>
Date: Tue, 2 Jun 2009 20:46:43 -0500

>From a viewer standpoint, I tend to like the "funnel your service requests
to the AD" because that makes it simpler to implement in the viewer, or at
least my fuzzy brain thinks that today.

Is it proper to assume that any grouping of services will be comfortable
forwarding their requests to the AD? At first glance, it feels a bit like
the AD is doing more than managing the agent, and feels like a bit of an odd
control point.

That said, should we be attempting to define what service belongs in what
collection? Different OGP implementations might want to group their services
differently.

> flow in a single request to the event queue cap?

Yes. Performance wise that seems to make sense, especially as more and more
starts showing up in the event queue path.

> the client as endpoints for messages flowing across the event queue.

This makes me think of another issue. The viewer's current way of thinking
is that messages on either  HTTP or UDP is valid and acceptable. What is the
expected behavior in OGP when group im is being handled by the AD, and
suddenly a group im message comes across from region UDP? Should the viewer
ignore it? If so, how do we do a runtime config of what messages are valid
(and trusted) from what sources?

> url. so the question is.. representing event_queues as URLs is not a

Ouch, head exploded.  :-). So do you mean that since
both "group:im:event_queue" and "search:group:event_queue" have the same cap
URL returned to the viewer, the viewer should only open one event queue to
that URL that expects to get both types of event queue traffic?

Suzy Deffeyes / Pixel Gausman
IBM