[OSM-dev] JOSM Plugin-Manager was: JOSM "simplify way" option

Christof Dallermassl cdaller.hw at gmx.at
Mon May 21 23:53:50 BST 2007


I see your point, but maybe it's time to end the time a plugin might do 
anything by accessing member everything it wants. I think you have quite 
a good overview of what is needed by a plugin and what not. Why not 
start to create some interfaces/callbacks/extension points/whatever is 
needed for plugins to obtain the things they want (layers, datasource, 
etc.). So at least new plugins could use the new interfaces.

But I know, it cannot be done in a day or two!

I know it was a design choice by Imi and it helps to develop quick 
(n'dirty :-).

What I do not think is that the current state prevents us from using 
version numbers for dependencies. Surely we cannot increase a minor 
number whenever an interface changes (as we do not have interfaces), but 
we still can try to define version numbers that represent internal changes.


change a Micro for bug fixes (not "interface" changes)
change a Minor whenever an interface changes
change a Major when a lot has changed.

I think JOSM does not change completely every day, so most of your 
changes will be a "micro" change and therefore will not break plugin 
compatibility - and if it breaks - well, at least we tried.

But having no such versioning scheme, we have not chance at all to 
indicate that a plugin will probably not work anymore. So its better to 
try and fail in 10% as not to try at all, IMHO.

> I suggest we add something to the plugins allowing them to advertise a 
> version or build number, and we put a machine-readable list of plugins, 
> current versions, and download locations somewhere. Then the user can be 
> shown a list of what he has and what's available, and any further 
> decision is his own.

Good point. I think we cannot do much more without rewriting JOSM and 
all plugins. But I still vote for Major.Minor.Micro versioning. Does not 
do any harm, but can be extremely useful in the (near/far) future.

> (We might of course also do it the Microsoft way, using a web service 
> where the current configuration is uploaded, and which responds with a 
> custom-tailored list. This would have the advantage of being able to 
> spot certain problematic things - "I see you are using plugin X version 
> 0.23 together with JOSM 0.87 which is a known problem configuration..." 
> - but the user would have to sacrifice a bit of privacy for that. And 
> then comes JOSM Genuine Advantage...)

and then JOSM in 3D with flying windows!

good nite

Christof Dallermassl
christof at dallermassl.at

More information about the dev mailing list