On 11/21/07, Tammo van Lessen <[EMAIL PROTECTED]> wrote: > Hi all, > > > So any opinion on both proposals? What are the parts that you like better? > > Tammo, did you have a look at AAM? > > I finally got the time to look at your simbpel proposal. Sorry for the > delay... > > Great work! And interestingly both proposals are indeed very similar > ;) I'm perfectly happy with merging the best concepts of both and > since AAM is way more complete, its probably the best starting point. > > Anyhow, I have a few comments/questions: > > o receive/invoke: For dealing with partnerLinks I'm more in favour of > our approach. I think indicating whether its a receive or invoke is > not explicitly necessary, instead it can be derived from it's usage > context. E.g.,: > partner.test(x); // invokes operation "test" on partnerLink > "partner" with inputVariable x > y = partner.test(x); // invokes operation "test" on partnerLink > "partner" with inputVariable "x" and outputVariable "y" > y = partner.test(); // a receive activity on operation "test" on > partnerLink "partner" with outputVariable "y" > This is in my opinion more intuitive at the same level of expressivity.
It is, but there's a lot of potential for ambiguity, at least two cases I can think of: the operation has no relevant input so you want to invoke it without a variable; when we need to pass correlation information to the operation, and those can be used on both receive and invoke. Separately, there's the issue of pick and onEvent, and although we can come up with a nicer syntax specifically for receive, I think it will help a lot if receive and onEvent end up looking the same way. > o Links: Great idea. Shouldn't the join method support more than one > link? I'd just drop the "link" parameter and would allow accessing > links directly in the expression language (like in BPEL). Then its > possible to synchronize more than one blocks. Or did I get something > wrong? It should have the same binary expressions you can use to join against multiple links, that's just an omission in the write up. Assaf > In general I'm a bit confused about which one of the approaches for > links is more intuitive. The signal/join stuff is IMHO more the > hackers approach (QT coders will love it), the other one is more > declarative, although I'm not sure whether it better w.r.t to > readability... What about considering both and letting the users > decide? > > Cheers, > Tammo > > -- > Tammo van Lessen - [EMAIL PROTECTED] - http://www.taval.de > -- CTO, Intalio http://www.intalio.com
