Unify preferences API

[michael2402]

This is just a WIP progress

The goal of our preferences should be to not depend on any other part of JOSM and should be as lightweight as possible.

Current way of accessing preferences is e.g.:

• Config.getPref().getBoolean
• new BooleanProperty().get()

We currently have a preference system that has many options to represent values.
Ideas would be:

• Drop the different settings types (list / map / list list) because they cover special cases. Tickets:
  • Imagery list #16872
• Provide a common way to convert all preference type. For each type we define
  • A serializer that converts the java value to a string
  • A deserializer for the other way around
  • A validation mechanism.
• Migrate the old list/map preferences to be simple strings.
• Drop the different setting access classes, provide a common way to register / access settings.

Alternative goal:

• Use some sort of classpath scanning to detect all settings that are defined on the classpath. Because we currently have the problem that available settings are not known to JOSM.

Alternatives are to change the preference format to JSON (would require big dependencies but automated serialization / deserialization)

[simon04]

Migrate some PreferenceChangedListener to ValueChangeListener

[stoecker]

Actually that ticket sounds strange to me. We go back to what we had? We had already "preferences to be simple strings" and went away from that, as it was unmanageable, hard to understand, hard to maintain.

Why should we go back to this?

Last sentence makes no sense for me. Why should the data format be responsible for any automatics?

I agree to get code streamlined and remove interdependencies, but not to the extent that we cripple the functionality. Clean code must serve a purpose. It is not a goal in itself.

[wiktorn]

There two things to be discussed and solved within this ticket:

1. Whether we allow users to easily modify preferences by editing preferences file? This will affect, which serialized form we should choose
2. API that we expose for preferences. Michael proposed, that we make preferences quite dumb and make objects stored in preferences responsible for providing serialization/deserialization methods. preferences module would provide basic types (more less, the same that we have right now, but without NamedColorProperty and StrokeProperty as they depend on AWT. Also - imagery module would be responsible for providing its serializer/deserializer for custom imagery entries. If any plugin would like to save some richer structure, it could just easily create serializing/deserializing methods and our module would handle that.

So to achieve 2, we discussed following options:

• move from XML format to JSON
• serialize everything to String stored in current preferences.xml

There's also third option:

• serialize to XML structure, by relaxing our preferences.xsd, so we have for example

  <xs:element name="property" type="xs:anyType">
    <xs:attribute name="key" type="string" use="required" />
    <xs:attribute name="class" type="string" use="required" />
  </xs:element>
  

And body of property is output of serializer and is fed to deserializer. It could be just a simple string, but it could be more complex structure.

This would give us the same flexibility as with JSON. The only problem that we have right now is that writing this serializers for XML will be a bit cumbersome without any external library. As far as I remember - XML libraries are 1.5-2MB extra, while gson (Google JSON serialization/deserialization library) is around 300kb. We could leverage gson library for automation of serialization/deserialization of POJO's.

I guess that because of first point (ease of modification of preferences.xml "offline" - i.e. without JOSM) we should reconsider if serialization to String is the best way to move forward.

[stoecker]

Replying to wiktorn:

There two things to be discussed and solved within this ticket:

1. Whether we allow users to easily modify preferences by editing preferences file? This will affect, which serialized form we should choose

That's not really a requirement, but I would hate to loose this.

2. API that we expose for preferences. Michael proposed, that we make preferences quite dumb and make objects stored in preferences responsible for providing serialization/deserialization methods. preferences module would provide basic types (more less, the same that we have right now, but without NamedColorProperty and StrokeProperty as they depend on AWT. Also - imagery module would be responsible for providing its serializer/deserializer for custom imagery entries. If any plugin would like to save some richer structure, it could just easily create serializing/deserializing methods and our module would handle that.

Again that's a way back. I.e. the color model was a simple string a long time. These properties have been introduced not so long ago. I'm not in favour of these classes, for me the string representation has always been enough, but there was a reason for making them.

I guess that because of first point (ease of modification of preferences.xml "offline" - i.e. without JOSM) we should reconsider if serialization to String is the best way to move forward.

Your plan also seems to forget, that you need a time when both must be present parallel. For a central component like the preferences this will have to be at least 1 year, more like 2 years.

I don't think that makes sense in the context that you think this should be done to decouple JOSMs code. You need to find a way to reach the desired goals without changing the on-disk presentation of the preferences.

[wiktorn]

Replying to stoecker:

I guess that because of first point (ease of modification of preferences.xml "offline" - i.e. without JOSM) we should reconsider if serialization to String is the best way to move forward.

Your plan also seems to forget, that you need a time when both must be present parallel. For a central component like the preferences this will have to be at least 1 year, more like 2 years.

I do not forget about that. And I plan to support format migration #16782 as anyway - I really disgust that adding new imagery property needs so much attention and much of the changes around the code and would like to simplify that.

I don't think that makes sense in the context that you think this should be done to decouple JOSMs code. You need to find a way to reach the desired goals without changing the on-disk presentation of the preferences.

My idea is to extend current format with new capabilities, so we are changing the on-disk format, but old data will be without migration code. What new we allow by changing XSD is other serialization formats.

I leave topic of colours and stokes to Michael.

[michael2402]

Replying to wiktorn:

I leave topic of colours and stokes to Michael.

Thanks

I already started working on it, but will need some more time. I plan on doing a smooth migration.

So far I'm collecting use cases for different formats and dynamic preference names (those are a problem as well, since their type cannot be determined in some cases).

I especially work may ways through the different places where preferences are used (=> some form of classpath scanning to really get the full list of advanced preferences and don't miss missing classes) (=> removing the need for dynamic preferences and replacing them by e.g. a map type)

The goal is to make it really lightweight and without any external dependencies, because we use it in every component of JOSM. And to make it Android-Compatible (no AWT)

[stoecker]

Replying to wiktorn:

And I plan to support format migration #16782 as anyway

Wrong ticket?

I really disgust that adding new imagery property needs so much attention and much of the changes around the code and would like to simplify that.

I think in that we all agree.

My idea is to extend current format with new capabilities, so we are changing the on-disk format, but old data will be without migration code. What new we allow by changing XSD is other serialization formats.

I don't understand what you want to say here.

[wiktorn]

Replying to stoecker:

Replying to wiktorn:

And I plan to support format migration #16782 as anyway

Wrong ticket?

Sorry, I meant #16872

My idea is to extend current format with new capabilities, so we are changing the on-disk format, but old data will be without migration code. What new we allow by changing XSD is other serialization formats.

I don't understand what you want to say here.

That if we take a bit different approach than in description of the ticket that I described in comment:4 - that instead of dropping current on-disk-format extend it in such way, that it will accept custom serializers, we will have easy migration forward without the need of writing migration code. I guess that this approach would solve the issues that've raised.

[stoecker]

Hello,

That if we take a bit different approach than in description of the ticket that I described in comment:4 - that instead of dropping current on-disk-format extend it in such way, that it will accept custom serializers, we will have easy migration forward without the need of writing migration code. I guess that this approach would solve the issues that've raised.

Sounds like a good proposal. I usually have no big feeling about the way internal code looks (assuming that all JOSM contributor do know what they do :-), but I don't like much changing external interfaces if no improvement comes form this.

As example we switched from XML to MapCSS as this was a big improvement. For the preferences format I can't really think of such big improvements, as our current format is very good. Slight improvements and internal changes are another topic and always necessary. And over time even slight improvements may mean a total rework. :-)