[Openstreetmap-dev] offline automatic processing prevention in clients (was: Editor question)
immanuel.scholz at gmx.de
Wed Jan 25 10:40:32 GMT 2006
[from openstreetmap at vr.ucl.ac.uk]
> If you require people to trace the nodes, then you also guarantee that
> at least one real person has seen each segment at least once, and made
> some attempt to say 'yeah, that looks about right'. That's really
This restriction cannot (and will not) be implemented in clients.
This is the same problem as example some file sharing clients (edonkey)
have a mechanism implemented in the client which restrict the download
based on the upload restriction to try to force people to allow more
upload to the network.
Such things don't work.
If people want something (like automatic processing of gps nodes), then
there will be clients that support this. (There ARE clients which
automatically upload several offline edited articles to wikipedia.)
If this usage scenario is not tolerable by the community, the prevention
has to be implemented in the server, not in the client.
To make my point (as coder) clear: I will implement what my users want to
(ok.. and what I am interested in too ;).
It is my strong believe in any open source environment, that there are
other coders out there which can also implement what they want, so if I
try to prevent something from beeing implemented (e.g. automatic
processing and upload of gps-data) then other will implement it, maybe
hostile forking my code. So I see no reason or success in trying something
against the needs of users.
Well, of course, this is a rather fundamental opinion and is not that
absolute as it looks in the first place. Of course I will to focus and
direct users to good practice with the server.
But if user want auto-processing, auto-uploading gps data to have fast
area coverage, you have to prevent this in the server (and if the need is
really strong, this could lead to a server code fork).
PS: I am sorry for my doom-mongering, but I've already seen projects where
exactly this inverted security models lead to frustrated server
administrators fighting with mass-sql-deletes agains frustrated users
fighting with own-coded clients.
More information about the dev