Hi, James -- > How about this for an idea of how we can get started (particularly if > the thought of another Jakarta Commons-like project scared some > people off :)...
No comment. > Then inside the Ode podling we figure out over time what BPEL stuff > we can merge etc. Over time the Twister code could merge/move into > Ode. BPM code from Ode could move into Agila. Or we can merge > everything into Ode, or Agila can become the BPM project again and > Ode can be the BPEL project - we'll see, we can figure that out > later. But the structure from day one would be we'd have a new > podling with a similar structure to the existing Agila project. I would think that getting everything into one place would be a good plan, and I could envision a unified functional testing framework (like the "Spexerciser" in PXE's codebase) as an initial deliverable that will ensure that there is a uniform notion of what a BPEL engine should do. I can't imagine swapping activity implementations between PXE's pi/actor machine and the backplanes that run BPE or Agila BPEL, but I can definitely imagine achieving quick consensus on a uniform BPEL parsing/static analysis framework, a uniform external eventing API, and maybe even a uniform debugging API so that all of the engines can plug into the same toolchain and the project can start feeding libraries to other BPEL-related efforts within Apache and elsewhere (like the Eclipse tooling project) and bubbling functionality up to the level that real users really care about. (Ultimately, users will care about good support for BPEL variants (1.1/2.0/other) and business-focused functionality, but engine plumbing is for the nerds.) > Does this structure seem reasonable to everyone? Sounds reasonable to me. Cheers. -- Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
