[josm-dev] License change plugin

[Frederik Ramm]

Hi,

Stephan Knauss wrote:
>> It shouldn't be doing background data requests, only send a request when
>> you explicitly ask for it.

> Yes, but then the request is running asynchronous in the background. 
> There is no visible user feedback the request is still running. If your 
> server has problems and is not responding for five minutes the thread 
> will still be stuck. You could change the "license check" button to 
> indicate a running request.

Or maybe simply not return control until the server's response has been 
fully parsed? I guess it is likely that people who push the button will, 
as their next action, want to investigate the results anyway.

> I quote the full paragraph so we have the context.
> Currently your plugin is doing license interpretation as well. Your 
> personal interpretation seams to be that if a node was created by a user 
> declining the CT it must be deleted. Even if it does not contain any 
> tags and is later moved. You rate it as Severity.DATA_LOSS.

> So in case the plugin wants to display a neutral view without 
> interpretation it must tag these nodes as Severity.POSSIBLE_DATA_LOSS.
> The only valid reason for DATA_LOSS would be if all involved users had 
> declined. The remaining mixed cases depend on the interpretation what 
> data needs to be removed.

Maybe we should just rename stuff in the interface then: red = "first 
version created by non-agreeing user", orange = "first version created 
by undecided user", yellow = "later version created by non-agreeing or 
undecided user" ?

Maybe we should do away with the distinction between non-agreeing and 
undecided users; anyone who is still undecided today is probably very 
likely to be unreachable and thus this would be a clear data loss.

Personally I don't think that a node created by someone who has not 
agreed can remain in our database after phase 5, no matter how many 
times it has been moved by others later, but I'll fire off a question on 
legal-talk and see what others say.

It is clear that the plugin isn't all-knowing and it will for example 
flag something as problematic even if it's only a case of 
hasse-osm-korinthenkacker having removed or added a "created_by" tag. 
Maybe we should allow users to define their own filters of what is 
considered problematic.

A big problem are still the "disagree to CT but agree to PD" people as 
they will be treated as "data loss" cases by the plugin.

When in doubt I would like to err on the negative side however - I 
wouldn't want to display something as safe when it later turns out to be 
affected by the license change. Because of that I am trying to think 
about how to analyse way splits and merges which generally lead to a 
shortening of history and might therefore unduly report an object as 
clean. But this is not an issue of the plugin, it has to be solved on 
the server.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"