Maciej,
2007/10/9, Maciej Szefler <[EMAIL PROTECTED]>: > On 10/9/07, Tammo van Lessen <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED] - http://www.taval.de
