Alex, I have commented inline. In general I'd say its about process.
Lance On 5/11/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Hi Bill, I think I speak for a lot of people when I say that we're all focused on implementing BPEL. This discussion is all about picking the right tool for implementing the spec. Nobody's on a quest to solve the general process calculus theorem. I'll draw an analogy from the compiler world, where you can either hand-code your own parser or you can use a general-purpose parser generator (e.g. YACC, ANTLR, JavaCC, and such) If you've hand-coded even a relatively simple language parser once, you already know what I mean. It's a hell of a job! It gets complex pretty fast, the code gets messy, hard to maintain and extend. So most of us prefer to use the best tool for the job which is a parser generator. Of course, we needed to learn about LR(0) or LALR theory, context-free grammars, reduction of tokens and other parsing concepts because it's a complex domain. But that's OK because we've already admitted to ourselves that we can't deal with the complexity of a hand-coded parser and we're willing to hit the learning curve because we see it as an investment rather than a cost or liability. The tools and body of knowledge around parsers raises the playing field and allows many of us to solve complex problems that would otherwise stomp even the best of us. I think this applies to Jacob as well. Admittedly, it's more complex than BPE but it's a framework that facilitates thinking and reasoning about concurrent and asynchronous operation. The relation to pi-calculus is more of a coincidence than anything. Fact is Jacob has proved to be very effective for implementing BPEL. The <foreach> case is a good example because Matthieu is a newbie when it comes to PXE (sorry Matthieu!) and it was his first foray into using Jacob. It was also an experiment for us to see how a new contributor could extend the BPEL runtime to support a new language construct.
Based on the email chain it sounds like Matthieu has found some of Maciej's time offline ( or I missed the conversation thread ) and has quickly come up to speed on PXE. All great but seems a bit anecdotal to building a community for the BPEL engine as well as the decision point for moving the "virtual machine" into the ODE trunk. Cory and I are spending a lot of time trying to understand the PXE "virtual machine" and get ourselves up to speed to discuss the technical merits of the engine and then move forward. Likewise, if there is anything Cory or I could answer about the BPE implementation we would be happy to do so. I don't think its unreasonable to ask that we hold off on moving the "virtual machine" into the ODE trunk until "we/the community" feel comfortable with the implementations and are all up to the same understanding. If this is just an issue for Cory and I then I ask for input from others. I think we can
safely say that it was a success. I take your feedback as the need to address the documentation side of Jacob and this is something we'll be happy to produce. In the mean time, I invite everybody to read up on the Actor model if you haven't already and ask questions if there's something you don't understand.
I
guarantee it will be worth your time and effort, well beyond the applicability to Jacob or BPEL for that matter. cheers, alex Bill Flood wrote: > The Ode charter was formed to implement BPEL, not solve a general > process calculus problem (of which the latter is dubious in the > context of the runtime as formerly asserted in well respected academic > circles). > > If somebody wants to implement a general process engine or go beyond > BPEL with all sorts of extensions, that probably belongs somewhere > else. I don't want the community to need to understand process > calculus to work on this project (or the theory of universal Turing > machines for that matter) - because it is not entirely necessary in > the narrow context of the implementation of Ode for BPEL. > > I prefer the BPE core for that reason alone - simplicity and focus to > the BPEL runtime problem. The engine does precisely what it sets out > to do in a straightforward manner, doesn't introduce extra overhead or > concepts, and we can explain it in terms anyone familiar with BPEL can > understand. Besides, it's documented. ;-)
