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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
