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 [EMAIL PROTECTED] ## N49°00'09" E008°23'33"
_______________________________________________
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
