[osmosis-dev] Switch to API 0.6 and interfaces

[Brett Henderson]

Jochen Topf wrote:
> On Tue, Jan 27, 2009 at 07:51:39AM +0100, marcus.wolschon at googlemail.com wrote:
>   
>> I am currently trying to switch the codebase of Traveling Salesman
>> to API 0.6 and since I need to change all the v0_5 to v0_6 I was
>> wondering if there was any reason we could not have an interface
>> Node/Way/Relation and V5Node/V6Node, ...
>> 90% of the code does not care about the version but:
>> * much code is dublicated and
>>     
>> * replacing the entity-classes requires you to copy all of
>>   the planet when piping your own implementations of entity-classes
>>   into or out of osmosis-tasks. (e.g. exporting map-data, downloading,...)
>>
>> So... how is everyone thinking about having an interface
>> v0_6.Node/Relation/Way and maybe even have the v0_6.Node
>> extend the interface v0_5.Node to ease the transition.
>> Since a v0.6-node has everything a v0.5-node has with unchanged
>> semantics. The only thing that changed was to add version-numbers
>> and make relation-members ordered (But any ordered list implicitely
>> still has the semantic of the v0.5 unordered, unmodifiable list).
>>     
>
> Why do we need different interfaces and classed etc. at all? Just use
> one class and have an optional version attribute. If its there, its there,
> if it isn't just put a 1 there.
>   
The duplication approach to new versions wasn't my original approach, it 
was the one that I eventually arrived at after a couple of false 
starts.  I *think* osmosis started with support for the 0.3 API, but it 
was 0.4 that became commonly used.  The change from 0.4 to 0.5 was 
fairly large and the Way object in particular changed considerably.  
Initially I tried to share as much code between the two versions as 
possible but it became a huge amount of work to factor out common pieces 
and create new versions of the pieces that changed.  I gave up and just 
duplicated most of the codebase using the current v0_x structure where I 
was free to make changes without fear of breaking the old version.  
Given that the old version is obsolete and should only receive bug fixes 
it doesn't seem that big a deal.  Copying data between different 
versioned objects only occurs during migration and performance overhead 
is minimal anyway so this wasn't an issue either.  With 0.5 to 0.6 the 
changes are less drastic with most changes being additional fields but I 
followed the same approach.  It gives me a chance to revisit the design 
and refactor without much pain.  Keep in mind that the majority of 
change isn't in the entity classes themselves, it is in the task 
implementations which often have to be duplicated anyway.

The two approaches suggested above (interfaces and optional attributes) 
to avoid duplication are very different solutions to the problem and 
very different to each other.  Marcus is coming from the viewpoint that 
he'd like to be able to pass his own objects through the pipeline that 
don't inherit directly from the existing Entity class, whereas Jochen is 
focused on making it easy to add extra attributes to existing Entity 
implementations.  Currently I've taken the view that I'll only support 
objects that I explicitly control because that makes osmosis easier for 
me to maintain.

My reasons against those two options are mainly around maintainability.  
I dislike optional attributes because it becomes a manual activity to 
ensure that all tasks support the correct attributes requiring more 
runtime testing.  I've avoided interfaces because some operations like 
sorting require fairly strict implementations of compareTo methods that 
are easily broken with custom implementations.  As a side issue, the 
current entities are somewhat broken anyway because their hashCode 
method isn't aligned with equals, it's one of the more tricky areas of java.

You are both attempting to minimise effort which is a good thing.  It 
just needs to be balanced against the effort of maintaining the osmosis 
core.  If you're both prepared to make these changes and support them 
long term then I'm prepared to look into it.  But it's not something I 
want to do on my own.  It's not trivial to revisit the code duplication 
at this point.

Brett