launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 4 June 2010 15:13, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:
> Well, FWIW I think that using atom/rss as the basic change detection
> mechanism for clients is a good idea, it lets folk that want to poll,
> poll using bog standard tools like google reader; pubsubhubbub as an
> optimisation on top of that would be very nice, and both of these
> things are very generic and extensible, so it wouldn't appear to limit
> us in any meaningful way, and should play nice with API's too.

Those are all true.  If we use a microformat within the published data
then it can be both human and machine-readable: for example it would
be nice to build a code review feed -> irc gateway, without needing to
effectively screenscrape the results.  It also builds on top of what
we already have.

If we're comfortable with this then the next step seems to be to add a
bunch more feeds, or maybe make it easier to add feeds, and then only
add pubsubhubbub when users are complaining about poll latency or
losas are complaining about load.  At the moment 90% of bugs seem to
be asking for more genres of feed.

> Building something completely custom would seem like an NIH approach,
> and I'd be very interested in why doing that would be worth it.

I'm not suggesting that; I should have said that #2 would sit on
RabbitMQ or XMPP or something similar.

> Oh, and there rabbitMQ of course, which we have deployed in the
> datacentre already and can do similar things to pubsubhubbub in terms
> of event handling, but its quite a bit more work to work with it from
> what I can tell.

So the nice thing about AMQP as I understand it is that I could say
"tell me about all comments ~lifeless makes on all reviews or bugs
across all products", without needing to first get a specific feed for
that created under ~lifeless.  I'm not sure this actually matters.
Implementing it may have difficult ACL issues.

-- 
Martin <http://launchpad.net/~mbp/>