[josm-dev] Refactoring of the JOSM architecture vs. Plugins

[Frederik Ramm]

Hi,

> Therefore I propose to refactor the current code base under the
> following assumptions:
> - It is not possible NOT to break compatibility with any plugin, so we
> better don't even try.

Anyone who refactors JOSM and willingly breaks plugins (that are checked 
in to SVN and are in use) demonstrates that he values his own idea of 
"code elegance" higher than the needs of our mappers. Revoke his SVN 
access and give him a GPS.

Of course nobody can complain if they've written their own unpublished 
plugin and your changes don't cater to their needs.

> - Identify plugins which might just as well be moved into the JOSM code
> base (I'm sure there's plenty of code which doesn't have to be a plugin).

We usually operate like this: Anything that doesn't have to be in the 
core for some reason, should be in a plugin. Imi was stricter than I am 
in this respect; I have e.g. incorporated mappaint into the core. But 
still I think there are many exotic functions that don't hurt the core 
but make it altogether more complex, so anything we don't absolutely 
have to have in the core should still be outside. What I'd really love 
to see is some architecture for lightweight plugins ("pluglets?") where 
you don't have to do a full-blown plugin just to add a "simplify way" 
function or so.

Maybe such a structure could be started as the strict plugin API that 
many seem to desire - but keep it simple at first, so that a "pluglet" 
can only do very limited things but in a strictly controlled fashion. 
Later, the scope of "pluglets" could be extended and existing plugins 
converted.

> - Introduce an API version management for plugins (let a plugin return
> its expected API version. Assume pre-version-management version on
> NoSuchMethodError).

These things sound so easy on paper. Even defining the API will be hell, 
consume days and days of work and add nary a feature to benefit mappers. 
After that you'll sit there and have API 1.0 and configure all plugins 
to expect 1.0. Later you make a little change and bump to API 1.1. What 
with the plugins? Will you make the core so that it supports older API 
versions? Will the plugins simply fail even if the change doesn't even 
affect them? *Lots* of paperwork you're introducing here, work that will 
be a burden to everyone who wants to contribute something in the future.

Anything else is fine with me as long as you don't go overboard 
"refactoring", i.e. change what needs to be changed and leave the rest 
alone (no wholesale refactoring just to be compliant with what people 
call "standard practice"). If you intend to create an altogether new 
JOSM then that's of course also possible but please call it JOSM-NG-2 
then and do it somewhere else. I still think that anyone wanting to 
refactor large-scale should rather invest his time in helping the 
JOSM-NG than running the risk of making JOSM into something the original 
JOSM developers can't (or don't want to) work with.

Bye
Frederik

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