ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tammo van Lessen <tvanles...@gmail.com>
Subject Re: ODE developement roadmap
Date Mon, 07 Jan 2013 13:18:56 GMT

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.


On Sun, Jan 6, 2013 at 10:43 AM, 韬吴 <testforvln@gmail.com> wrote:

> 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 ;).
> >
> >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

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