[OSM-talk] Live Data - all new Data in OSM
zerebubuth at gmail.com
Wed May 13 19:25:55 BST 2009
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
> 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.
More information about the talk