ODE developement roadmap

[Tammo van Lessen <tv...@gmail.com>]

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

Re: ODE developement roadmap

[Gary Brown <ga...@pi4tech.com>]

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 <tv...@gmail.com> 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