launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

So, as part of looking after a young baby, one sometimes finds oneself
up at odd hours, and then cannot sleep ;)

Having just had that experience (again) I thought I'd jot down some
(possibly sleep-deranged) ideas I've had around longpoll.

Firstly, I think the shared workers approach is good - its a direct
action on the thing we're having problems with rather than going
around the edge and hoping. William has noted some alternate ways we
could support the same facility on Firefox in the interim in the bug
in question.

Secondly, we currently hand out a unique *queue* name to each
subscriber, which is allocated by LP. I think we should change this to
instead be handed out by the long poll service itself: this will allow
direct requests to be made of the service without needing a handshake
with LP. The existing mechanism looks roughly like this:
 - LP makes a queue with a UUID name
 - LP subscribes the queue to the notifications relevant to the page
 - LP hands the queue UUID to the browser that then starts [long]polling

If we instead:
 - browser requests a new queue from the longpoll service
 - queue is created and returned w/no subscriptions
 - subscriptions are requested by the pages visited (either by asking
LP and supplying the queue UUID, or by asking longpoll - see below)

then we've got clearer separation of concerns, which will fit better
with a shared worker model - and LP itself doesn't need to get into
queue creation (or not). Indeed, we might want to not create queues at
all but instead just subscribe to the appropriate topics from a single
longpoll daemon, if/when we get into 10's of thousands of connected
clients: do the last-stage routing in the longpoller itself : that way
the longpoller won't be receiving the same message multiple times from
rabbit. Making LP itself unaware of this distinction would allow us to
do such a change in future without updating LP, or any other services
that also want to have their clients consume longpoll.

Allowing longpoll clients to request specific subscriptions would be
very interesting. The current security model is that the LP appserver
creates all subscriptions, so private object subscriptions are safe:
you cannot guess at the queue UUID, and LP itself has to make the
subscription. We can preserve this safety by ensuring LP is involved
in vetting new subscriptions in some fashion (either by a longpoll 'is
this subscription permitted' callback, or by having new subscriptions
be requested of LP itself). However, there are some very interesting
use cases that we only currently support indirectly: subscribing to
new objects. E.g. subscribe to launchpad/+bugs to get notified on
changes to the bugs collection, that can safely trigger (knowing there
is a change to the number of bugs doesn't disclose the content of the
new bug if it is private). It might be nice to have a way to get
notified of the bug numbers though (or team names etc for other
objects). Ideas sought about how to efficiently hook such a more
direct facility up without making the common case (subscribe to a
concrete object which can be seen) more awkward. I think in the
absence of a simple plan we need to just document how we will assign
routing keys (and thus subscriptions) to virtual objects (such as
'launchpads bugs', or a specific bug search) and accept that web pages
showing those objects will fire off an AJAX request after being told
about the update.

-Rob