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: Extending ODE
Date Tue, 09 Oct 2007 19:57:04 GMT
Maciej,



2007/10/9, Maciej Szefler <mbs@intalio.com>:
> On 10/9/07, Tammo van Lessen <tvanlessen@gmail.com> wrote:
> We'd like to avoid binary compatibility changes as much as possible since
> they are very disruptive. So I would suggest that the runtime code check the
> field containing ExtensionAssignOperations for nullity and interpret this as
> "no extension". This will allow for backwards compatibility, since
> Serialization can handle new fields popping up.
I'm not sure whether I got you correctly, IMHO the problem is that the
order of the elements in a <assign> is important. In the 'old' OAssign
there was only a field containing Copy objects. I'm not an expert in
preserving binary compatibility. Would it help to have both, the old
'copies' field and the new 'operations' field that contains both?

>
> because the OAssign class was changed to contain both Copies and
> > ExtensionAssignOperations. Additionally the compilers knows now how to
> > handle <extensionActivity>, <extensions> and <extension> elements
and
> > also checks whether extension namespaces have been declared or not.
> > The compiler DOES NOT check whether  the implementation of an
> > extension is installed since the compilation does not necessarily take
> > place on the same system.
>
> I think I agree with Alex on this. The general approach thus far (for
> example if you look at the way expression languages are handled) has been to
> provide a compile-time component and a run-time component. It's  a little
> bit more of a hassle, since the compiler has to be informed of the available
> extensions, but worth it in my view.
Is the important thing to verify that the extension expression is
valid or is it about performance? So currently I only store a
SerializedElement in the O-model, this means that the o-model is
independent of any further extension. If the former is the important
thing, then it might be sufficient to have an extension point for just
validating the expression, wouldn't it?

> > The execution of the extensions is actually straight forward. One
> > thing we should discuss is : Is there a need to support 'new'
> > structured activities. If so this is gonna be tricky as the extension
> > developers needs access to Jacob specific stuff. Opinions on that?
>
> so... per above, a definite yes on access to JACOB specific stuff; otherwise
> the extensions will be rather limited in power. Of course that is not
> suggest that there should not be some way to easily implement extensions
> that do not need that additional baggage.
Hmm, I just hoped to receive a clear -1 for that feature :) I think it
can be pretty difficult. I'm not the Jacob expert, but wouldn't this
imply that extension developer need to create new ChannelListeners
etc.? I would prefer to go firstly for the basic activity variant and
wait for some use cases (here is the first: an activity like a flow
but with a rule engine *g).

The more I think about it, it could be solved by making the
runtime/jacob part more visible (wrt to the method visibility).

> Great job btw. I have a feeling this will be a very popular feature.
> -mbs
Thanks, hopefully :) AFAIK we're providing the first BPEL engine (at
least in the OS sector) with such a feature :)

-- 
Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de

Mime
View raw message