ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 韬吴 <testfor...@gmail.com>
Subject Re: ODE developement roadmap
Date Sun, 06 Jan 2013 09:43:42 GMT
I'm interested in implementing new serialization, how can I get
involved in development?

Tammo van Lessen <tvanlessen@gmail.com>  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 ;).
>  Tammo
>[1] http://code.google.com/p/jdeserialize/
>[2] http://dozer.sourceforge.net
>Tammo van Lessen - http://www.taval.de

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message