[OSM-dev] TRAPI status

[Brett Henderson]

On Wed, Mar 10, 2010 at 7:30 PM, Peter Körner <osm-lists at mazdermind.de>wrote:

> >     I started working on a streaming XML output plugin for Osmosis. I
> >     was intending to take advantage of PuSH/PubSubHub messaging and
> >     maybe even XMPP (so that you get a 1-min delayed IM when someone
> >     changes something in your bbox).
> >
> >     Anyway, TRAPI could use this same plugin to apply updates to their
> >     database.
> >
> >
> > I've also spent a fair bit of time thinking about this type of thing.
> > When I first started work on the replication diffs I had in mind a
> > server-side daemon (using Osmosis internally) that would push changes to
> > all connected clients.  It would allow a client to connect, specify
> > which replication number it was up to, receive all updates in a single
> > stream, then continue to receive live changes as they occurred.
>
> Unless there is some kind of filtering involved, i don't see the
> advantage over the current replication approach (despite of bandwidth,
> maybe).
>

The main advantage is a huge reduction in latency by elimination of most
round trips.  The longer term advantage this leads to is allowing the
current minute replication to drop to even lower intervals (eg. 5 seconds).
But I'm not sure how useful this would be in practice.


>
> But if I can subscribe to all changes in a bbox or to all changes on
> ways with a highway-tag, then there's a real big benefit, as i don't
> have to deal with all changes (which is quite a huge amount of data) but
> only with those things I'm interested in.
>

I could see it being a useful tool.  It would require a database of some
kind to allow these types of queries to be performed.  But it could be done
outside the core infrastructure which reduces the number of hurdles to
overcome.  All it requires is somebody willing to have a crack at
implementing it ;-)

Cheers,
Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100310/dbc1bb37/attachment.html>