[josm-dev] Jumbo Patch

Frederik Ramm frederik at remote.org
Mon Dec 17 02:09:37 GMT 2007


Hi,

> I have reached situations like this many times. My gut feeling is
> that the JOSM core needs to be redesigned. Conceptually, in the
> greater scheme of things, what JOSM does is not that complex and it
> should be possible to come up with a highly optimized, extensible
> core that does everything needed. If this where to go ahead, then it
> would make sense to design this with OO principles in mind to make
> it maintainable. If a new plugin or piece of code needs to hook into
> something in the core in a non-standard way, then we add the
> appropriate hooks into the core to allow this to happen.

This sounds like it would not make a lot of sense to keep anything of
the existing code. It's more like saying "ok, JOSM was a good
prototype and we have learnt some things about usability, now let's do
it properly".

Which would probably not be the worst thing to do. We could start a
"JOSM NG" on the side while still using the existing JOSM for
production, and once JOSM NG has enough features, we switch.

(Personally I'll be pragmatic and continue to improve JOSM "classic"
until the day a working substitue is available, but I won't stand in
anybody's way if they set up a JOSM NG project and wouldn't feel
offended either.)

On the other hand, if we re-write anyway, then we might just ditch
Java altogether and do it in C++, or maybe simply use Merkaator as a
start (don't know how well it is designed on the inside but it is a
fast C++ app that compiles easily on Win, Mac and Linux which is
probably enough for us). If people are really concerned about memory
usage and such (as in "you can't keep a list of ways with every node
as even the empty list will consume 80 bytes") there's just no beating
good old C++.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'





More information about the josm-dev mailing list