On 09/12/09 20:27, Peter Körner wrote:
Such an api could create heavy load on the underlying database, what is
AFAIR the main reason why such calls aren't implemented in the current
api. But unlike on the main api, queries to an such a history api don't
need to be answered in miliseconds.
Hi,
Tom Hughes wrote:
You may not mind that it takes 15 minutes to answer your query but the
problem is that long query times like that probably won't scale because
if an average query takes 15 minutes then the server (assuming that
we're talking an I/O bound process) can only handle four
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Frederik Ramm schreef:
Tom Hughes wrote:
You may not mind that it takes 15 minutes to answer your query but the
problem is that long query times like that probably won't scale because
if an average query takes 15 minutes then the server
Hi,
80n wrote:
Something like this is well within the capabilities of XAPI and I had
already downloaded a copy of the full history and was just starting to
think about what should be done with it.
Stefan de Konink wrote:
Already forwarded this e-mail to the head of our department to get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Frederik Ramm schreef:
I wonder if there is already an Internet law that says something like:
Those with the most energy to solve a problem will likely also be those
employing the most exotic tools to do it.
Oh, yeah I could ofcourse
Hi Peter,
as far as I can see all that you've described will be available in the
new OSMdoc version (including 'minor' versions when a node for a way
is updated).
This is if everything goes according to plan and I don't have to
delete a whole bunch of data because of the license change.
But the
6 matches
Mail list logo
