On Wed, May 13, 2009 at 6:30 PM, Frederik Ramm <[email protected]> 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 _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
