On 10/9/07, Tammo van Lessen <[EMAIL PROTECTED]> wrote: > > 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'm a bit confused here; I would have thought the extension would/could register into the compiler to parse and validate the extension code and then generate the necessary O-model objects. Is this possible? I think compile-time validation of BPEL extensions is quite important. I agree we do not require the runtime implementation to be available at compile-time. Here I'm still not sure whether we should abstract from the O* classes > and provide a simplified API or that we want the extension developer > to have access to the whole obj-model. What do you think? I would go with the full O-model rather than a simplified API unless someone wants to make a case for the portability of extension bundles. Except for simple cases, I assume intimacy is required between extensions and the engine. These extension bundles can then be registered to the engine via Ode's > config file (comma separated list of class names). During hydration, > the engine checks for mustUnderstand extensions and throws an > exception if there are no extension bundles registered for them. Excellent. 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? I think we should cross that bridge when we have a couple use-cases lined up. Looking back on the activity failure extension, I don't see how we could have provided a decent API to support that work up-front, or even now. This lends me to believe that structured activity extensions need to be part of the engine. I think thats basically it, of course I'm curious what you guys think of it. I like it! Should we also add an "extension zoo" to list our own and third-party > extensions? Yes, definitely! Where should we put our own extensions? (sandbox, or trunk/extensions, > or something?) I would go with trunk/extensions. That way, the lifecycle is the same as the engine so it's easier to checkout, compile, and use together. I'm currently working on an extension that allows for using > Javascript/E4X within assign activities. This was actually thought as > an example but now I think it is way too cool to be just an example :) Indeed. This is one we've had an eye on for some time. I think we should support it as a base extension for Ode. alex
