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. o How do you identify the role of a partnerLinkTypes in partnerLinks? 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? 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
