Hi Tammo +1, agree this is best way to overcome the current backward compatibility issues.
Regards Gary On Fri, Dec 21, 2012 at 12:04 AM, Tammo van Lessen <[email protected]> wrote: > Hi ODErs, > > I've been intensively discussing with Hadrian about Jacob, its > architectural placement in ODE and the current status of the trunk. First > some thoughts about Jacob: Actually, we believe Jacob is meant to be an > actors/pi calculus framework that may serve for any application like ODE. > However, Jacob does not provide all means that are needed to have a clean > abstraction. In order to make it more "frameworky", we would need to > provide clean abstractions for cross-cutting concerns like logging, metrics > and also persistence (i.e. the serialization part). This would sharpen the > component boundaries and would make it also accessible for other > applications. I think it would be a good idea to give Jacob some love and > some post Java5 goodness. > > The work on Jacob also touches another issue we have right now with trunk, > which is the lost backwards compatibility with the 1.3.x branch. > The problem is, that there is no easy way to fix this in a future-proof > manner while fully maintaining backwards compatibility. Matthieu once tried > to achieve that in the ODE 2.0 branch by allowing ODE to use and run > multiple OModels and runtimes in parallel. Although this eases the pain a > bit, it does not provide a real migration of old OModels to newer ones. I > believe the best way to put this on a better level is to reimplement the > OModel using Maps as the backing structure and to get rid of the use of > Java's built-in serialization. Instead we can use JSON (or Smile), powered > by Jackson, which is even faster than Java serialization. That way we can > change the OModel without breaking the serialization/deserialization, and > can react on model changes by tweaking or transforming the JSON after > loading it. I think this would be a future-proof approach. > > If you agree with that idea, we'd start to do that refactoring in order to > overcome the impasse. We would call the trunk then ODE 2.0 (again...) and > will at this stage no be backwards compatible to ODE 1.3.x. This makes > actually no difference as there is no backwards compatibility right now as > well, but the new major version makes this clear. > > The backwards compatibility to ODE 1.3.x, however, can be addressed in > several ways: > 1. Load the 1.3.x OModel and serialize it to JSON. Tweak the output so > that the new OModel deserializer can read it into the map-backed model. > This may happen either in ODE 1.3.(x+1), in ODE 2.0 or in a standalone > migration tool. > 2. Directly read the object stream of the old OModel and serialize it to > JSON without loading it to an old OModel version. This could be done e.g. > by using jdeserialize [1]. > 3. Load the old OModel and map it to the new OModel using tools like > Dozer [2]. > > For the progress's sake, we would focus on the refactor-first approach, > accepting the loss of backwards compatibility while having in mind that a > migration path exists and can be implemented when needed (or volunteers > show up, or course ;). > > WDYT? > > Best, > Tammo > > > [1] http://code.google.com/p/jdeserialize/ > [2] http://dozer.sourceforge.net > > -- > Tammo van Lessen - http://www.taval.de
