I'm interested in implementing new serialization, how can I get involved in development?
Tammo van Lessen <[email protected]> Fri, 21 Dec 2012 01:04:2： >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 > >
