[Tm4j-developers] Future of Panckoucke

[Harald K. <har...@we...>]

Hi All,

As panckoucke evolves, I see that it could be interesting not only for TopicMapVisualisation but also for the Visualistation of other Data. I think that this is something nobody objects against.

However, as a generic Visualisation Project would not fit within the scope of the TM4J Project, I suggest moving panckoucke into its own Project on SF.net. I would like to suggest splitting the panckoucke development into two branches. The first one will clean the existing code and add certain functionality (like basic support for editing and basic support for generic data abstraction) without breaking compatibility with panckouck 0.3.1 (at least not in a major way) This will be called panckoucke 0.4 (PK 0.4) 

In Parallel inside a new founded panckoucke Project on sf.net, development for the new panckoucke will start. This (well the first release) will be called 
panckoucke 0.5 (PK 0.5), Its goals are to create a new Model API, make panckoucke a generic Data Visualisation Framework (without loosing the strong connection to TopicMap Visualisation) and in the end, port the PK 0.4 stuff into PK 0.5. 

TMNav as the Reference implementation should definitly stay inside the TM4J Project.

As this means a lot of work which can be made parallel, I would also like to suggest that two different persons take resposibility for the different branches. I would personally volunteer to take over
resposibilty (and probably most of the work) for PK 0.4. I also think that Christoph should be responsible for PK 0.5. Other people like Niko, George and his team as well as Jens and Stefan or anybody else interested would be more than welcome to contribute.

The reasons for doing this parallel work are:
- both branches could be developed independantly, so the clean up and refactoring could be done without having to wait for the new Model API
- i also think, that this would speed up development, as the features and changes introduced in PK 0.4 could be tested and applied in tmnav without the need for the new model api to be in place
- i think that the major argument against moving the whole codebase at once is that, if we move panckoucke into a new Project, then why "pollute" the new CVS with packages that will be changed soon anyway (new model api, possibly new package structure)

Cheers,
Harald

_________________________________________________________
Mit WEB.DE FreePhone? mit hochster Qualitat ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201