Re: [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Xuân B. <xua...@ba...>]

Conal Tuohy wrote:
> Hi Xuân
>
> I'm not convinced, actually.
>
> It seems to me you should have introduced a new, TMDM-flavoured
> TopicMapObject interface,
I did, see here: 
http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/TopicMapConstruct.java?revision=1.1&view=markup
> rather than changing the old, XTM
> 1.0-flavoured interface.
>   
I did not change the old XTM 1.0-flavoured interface except for this one 
abstraction of equality.
> As you yourself pointed out, the getID() method isn't appropriate for
> TMDM-based topicmaps, so a distinct interface for TMDM TopicMapObjects
> is probably better (rather than an extended one, with "deprecated"
> bits).
>   
There is, as 
org.tm4j.topicmap.tmdm.TopicMapConstruct.getItemIdentifiers() shows.
> Personally, I think your effort to unify the XTM 1 and TMDM models is
> too ambitious
I don't unify into a greater model.
> (although I don't know how you intend to achieve this
> goal, because you haven't described your plan). It seems to me though
> that you should instead have two distinct models,
I do.
> and to use a layering
> approach to unify them.
I do. 
http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/tm4j1/ 
is the translation layer.
> The two models are IMHO not sufficiently
> compatible to be simply "merged"
I agree.
> (as you have started to do).
>   
I do not think so.
> Mainly, though, I just think it's important to fully discuss these kinds
> of disruptive changes before instituting them, or else they should be
> done in a branch. The trunk is not the proper place for this kind of
> speculative work.
>   
The equalsByID() thing was done as fix to a specific problem, as far as 
I remember. It is not breaking any code using the API, and I was not 
aware that there was any code outside of TM4J actually implementing the 
API. Thus, it was reasonable to not expect any problems.
Additionally, I considered (and still consider) this API "public, but 
extendable" (although I do not intend any further changes). But even 
though I do know now that there is external software implementing the 
API, I still think an approach like it is done with the Linux kernel is 
appropriate:

   1. What is in the kernel gets refactored appropriately by those who
      do the refactoring.
   2. What is outside but implements an inside interface has to be
      updated by the outside maintainers in order to mirror the kernel
      development.
   3. Development freeze (=stopping changing APIs) over extended periods
      of time is unacceptable.
   4. Who wants to be really conservative and not go the way of being
      up-to-date (both regarding breaking code and regarding reaping the
      fruits of the development) may stick with an old version.

So, I consider a change in a project imposing a need of a change in an 
unknown external dependent project of 3 lines not necessarily 
disruptive. It is just normal that APIs evolve for certain needs (such 
as speed and reduction of side effects), and that external projects 
implementing these APIs need to implement new methods in these APIs if 
they want to mirror the development.

Additionally, specific to TM4J, there is low to virtually no activity on 
the project in the last 12 months (at least when I exclude commits by 
myself), so even for major (API) changes, there is not really any reply 
expected. Thus, it is quite unreasonable to ask and wait for no reply. 
Thus, I think, if there is any progress to be expected at all, the 
burden of disagreeing (like writing e-mails and debating pros and cons) 
should be on those being otherwise passive (i.e. by default every change 
is allowed unless challenged, not by default every change is denied, 
unless allowed).

I'd like to ask you to make your API implementation publicly writable 
(e.g. import it into the TM4J project under some open source licenses), 
then bad surprises like a need to adapt to new versions can be avoided.
> Regards
>
> Con
>
>   
ciao,
Xuân.