ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject [DISCUSS] Jacob refactoring
Date Thu, 25 Jul 2013 01:57:24 GMT
I just pushed a new commit eb870cc944b8c6364edb41156b9148e95b7ea4ad to 
the ode trunk, upgrading jacob from the old local implementation 
ode-jacob to jacob-2.0-SNAPHOT which lives in a separate git repo after 
the migration to git.

A few months ago Tammo and I explored some ideas of refactoring jacob to 
make it simpler, possibly faster but most importantly easier to 
understand. After some refactoring around Channels that removed the need 
for generated Channel(s) and simplifying the ChannelListener 
implementation, Tammo did some really cool stuff around serialization, 
moving from java serialization to json, which is not only faster but 
allows for a better understanding of the ingredients in the vpu soup.

Now it's time for more refactoring after the promising results of the 
first round. The goal however is to implement all these changes in a way 
that is not too disruptive to the rest of the ODE code base, hence the 
commit referenced above. As the jacob refactoring moves on, we plan on 
deploying timestamped snapshots and keep the ODE trunk in sync with the 
last jacob snapshot. Most of the development will go on branches and 
stable versions will be merged to trunk. We also discussed and hope to 
release a 1.3.6 version soon.

That said, the jacob improvements ideas revolve around simplifying 
usability and provide a simpler mapping for the pi calculus concepts 
jacob implements.

The Continuation concept reflects the sequential execution of two 
processes (P.Q). As they are executable, the JacobRunnable concept is 
not really necessary, Runnable would suffice. Using java reflection via 
Method.invoke is not necessary either if we make the convention that all 
processes MUST be Runnable (which is the case already actually).

On the Channel side, we think that the interface is unnecessarily 
flexible, which imposed the need of using dynamic proxies. The rationale 
for that is a bit more complex and has its roots in various 
interpretations of pi calculus and the desire of the initial authors to 
provide a bridge to object oriented programming. That aside, restricting 
the Channel interface to something like:

interface Channel {
     void onMessage(Message message);

... eliminated the need for Proxies, but may be prone to errors due to 
the loss of static typing. That could be addressed though via static 
typing of Messages (kinda like the the Actor model does it in Akka or 
Erlang). This change adds the fringe benefit of also supporting an event 
sourcing style [1] of executing the reactions in the soup [1]. This is 
something we'll investigate later.

Finally, the JacobObject concept is a bit of an odd design artifact, as 
it semantically maps to the operations in pi calculus, not to object per 
se. This is also something I will take a look later, but I expect the 
JacobObjects to disappear, or be replaces with something simpler.

Another area I plan to investigate a bit later is a small DSL closer 
aligned with pi calculus, hopefully easier to use and promoting better 
understanding of process execution and reduction cycles.

Thougths highly appreciated,

Hadrian Zbarcea
Principal Software Architect
Talend, Inc

View raw message