[josm-dev] JOSMng prototype [resend]

[Gabriel Ebner]

On Wed, Feb 06, 2008 at 03:42:27PM +0100, Petr Nejedly wrote:
> As there was a general refusal of large data structure redesign with
> a proposal to do something along the lines of josm-ng, I tried implementing
> the data structures with a bit scalability in mind, just to test where can I get
> with what kind of effort.

Wow.  That's great.

> MVC patern:
> The model is clean data set. It contains only the primary data and their
> modification status. It uses as little memory as feasible (A node with no
> tags - or "created_by tag only" - needs just a single heap object).
> The model has all the data fully encapsulated and all the modification
> generate and post undoable edits.

Impressive, you're even sharing the tag values.  Next thing you'll tell me is
that you've specialized a way class for ways with only two nodes. :-)

> File->Open (blocks UI for a while currently)

Albeit only half as long as JOSM.

> Displaying the data set.
> Styles implementation parsing elemstyles.xml
> Zoom (mouse wheel), pan (right button), node movement.
> Basic change coalescing and undo of node moves.
> And most importantly, reasonable repaint/edit performance at all zoom levels.

BTW, I'm getting lots of "Average shift before rehash is 1.0227355" messages.
Did you roll your own hashtable?

> I'm not attaching the sources now (I have used few JOSM concepts and icons
> but no code, so everything but the style data is (c) by me), but have no
> problem providing the sources under reasonable license if there is a demand.
> (Current JOSM's GPL was already questioned here).

Would it even be possible to rewrite JOSM under a BSD license now?  I'd
thought most of the likely contributors would be too contaminated by GPL'd
code.

> While I would like to continue productizing the prototype, I have very little
> time for this effort (I actually wrote most of the code around Christmas) and consider
> it mostly exercising material. Moreover, current JOSM has some plugins and a lot of
> code that would need to be (with slight modifications) duplicated in josmng,
> so I would, obviously, like to see the code land in the trunk somehow.

There are some parts that would very likely need more than mere duplication,
i.e. a major rewrite (or even redesign):
  - Merging
  - Selection
  - Actions
  - Uploading
  - Validator plugin

However, I don't really feel comfortable with cutting-and-pasting your code
into trunk and be done with it.  If we're doing a rewrite, why do it only
half-way?  Quite a bit of code in JOSM dates from a time before there even
were ways.  Multiple data layers are only a recent change (look how undo is
handled) and were added as an afterthought.

IMHO at least merging, selection and uploading should be implemented within
josm-ng; then JOSM could be ported to use josm-ng as a core library (as was
already suggested in another thread).

In any case, I've got some time to spare during the following two or three
weeks and would love to make JOSM snappier than ever.

  Gabriel.