[OSM-dev] JOSM Plugin-Manager was: JOSM "simplify way" option
frederik at remote.org
Mon May 21 21:56:47 BST 2007
> * plugins depend on other plugins, ensure that they are available and
> loaded before.
> * so we need versioning in plugins/JOSM to be able to define the plugin
I see problems there.
JOSM doesn't have a very strict plugin interface. It has many public
member variables all over the place, so that plugins can do virtually
anything and are not restricted to doing things that the JOSM authors
thought plugins might want to do.
This has been a design choice by Imi, and is very much in line with the
spirit of the rest of this project (don't do complex designs beforehand,
just leave it as open as possible and the community will make something
good of it).
Replacing this openness in JOSM with a catalogue of things a plugin may
or may not do, and interfaces to go along with that, would make JOSM and
the plugins more complex and reduce the play room for people developing
But without such strict interfacing rules, we will never ever be able to
formulate dependencies correctly. The only thing that I as a plugin
writer can say is that my plugin works with the JOSM version I wrote it
against. I can never be sure that it will work with future or past
versions, and that it will not break other plugins (or be broken by them).
Because of this, we will not be able to have automatic procedures
dealing with plugins and dependencies. You can say something depends on
something else, but you can never say which version. Any attempt at
automatically downloading things runs the risk of downloading
non-matching things, and is sure to alienate the user who expects that
if the machine automatically downloads stuff, it will surely work.
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.
(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...)
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'
More information about the dev