[OSM-talk] Live Data - all new Data in OSM

[Matt Amos]

On Wed, May 13, 2009 at 6:30 PM, Frederik Ramm <frederik at remote.org> wrote:
> Matt Amos wrote:
>>
>> i think if we can get the delay on the diffs down from 5 mins to under
>> 2 mins then there's no reason why streaming can't be built on top of
>> the diffs and be able to support all the things people want to do with
>> streaming.
>
> What you are talking about is "simulated streaming" not real streaming. But
> it would be a good start; establish some kind of simulated streaming that is
> based on the diffs and costs us almost nothing (can be done by someone on
> their own server off-site!),

indeed! good, isn't it? ;-)

> and when interesting applications spring from
> this where everybody says "oh if these could only be real-time instead of 2
> minutes delayed" then one an still work on providing the same stream in a
> live fashion.

given that nothing is ever truly live - there will be a processing
delay with any method - whats the real advantage in a 2 minute delay
rather than a <1 minute delay?

> By the way, if someone really wants to chase the edge of the database by
> always downloading the latest minute diff, what is the suggested way to do
> this? If he makes only one GET request per minute then the diff he is
> looking for might already be 59 seconds delayed ;-)

yep... but does another 59 seconds really matter? ;-)

> can any of today's hip &
> trendy messaging protocols be used to painlessly notify anyone who is
> interested that "there's a new diff ready", instead of having over-eager
> scripts poll the directory every 10 seconds?

i guess it would be fairly easy to have a CGI script for the "next
diff", i.e: after receiving the request it blocks until a new diff is
ready and then returns that diff.

cheers,

matt