Hi, thanks for your interest in this, your work on this is highly appreciated. For a quick start you may look into this thread: http://markmail.org/message/c4aq7li2p5u4a5kh#. Since this is a rather complex task, we should discuss the architecture on this list first. I'd suggest to start the implementation on a git fork/branch and then send us a patch or a pointer so that we can merge your changes into the main trunk.
Thanks, Tammo On Sun, Jan 6, 2013 at 10:43 AM, 韬吴 <[email protected]> wrote: > 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 > > > > > -- Tammo van Lessen - http://www.taval.de
