[OSM-dev] 0.5 API: /api/0.5/user/preferences, values truncated to 256 chars

[Andy Allan]

On Tue, Nov 25, 2008 at 5:21 PM, Chris Browet <cbro at semperpax.com> wrote:
>>
>> What we could do is to make it update the preferences that are sent,
>> rather than deleting all the preferences. This would be done as a POST. Also
>> being able to fetch all preferences that start with a particular key may
>> prove useful for things like editors getting all their prefs.
>
> That seems very good. I didn't quite understood the reasoning behind the
> "delete-before-update" paradigm. It makes the client quite heavier, as it
> has to save all the preferences that don't belong to him, merge with its
> own, then upload (that without taking into account the undocumented
> "update_one").

It's analogous to the rest of the tag-based API though - you can't add
a tag to a way without client-side reading of existing tags, adding
yours to the list, and posting the full list back to the server.
Whether that's done by delete-insert or read-examine-update behind the
API is a different matter, but even if it was optimised to not do a
delete_all, the concept in OSM parlance is still the same - omission
of a tag from list of tags is an implied deletion of the tag from that
list.

Not many ways have 150 tags, mind you, and user_preferences doesn't
have a history to recover from scripting errors. So I'd be happy to
see an exception.

Cheers,
Andy