Re: [ogpx] event queues for fun and profit

[Suzy Deffeyes <[e-mail]>]

On Tue, Jun 2, 2009 at 5:22 PM, Infinity Linden <[e-mail]>wrote;wrote:

> so... event queues...
>
> * 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?


>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.



>
> * message count - should we let multiple server -> client messages
> 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.


>
> * 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.


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?


>
>
> * 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?


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