Re: proposal for shortcutting <operation> syntax for simple operation patterns

I've extracted some points from the presentation, and present responses
here.

On Mon, 22 Sep 2003 12:41:35 +0600
Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:

>Rationale
>Requiring users to remember pattern URIs for the commonly used patterns
>is unacceptable

No.  It is necessary.  It is not burdensome.  It is much more
straightforward than interpreting sequences of input/output.

>Requiring users to remember the names chosen by the pattern authors for
>the messages is unacceptable

Not really.  Maybe in the case of the most common patterns, it is.  But
that supports making @messageReference optional for patterns containing
only a single message in a given direction, not optionality of @pattern.

>It would be better if error-prone redundancies were eliminated

Agreed.  This justifies making messageReference optional for all
patterns in which there is only a single message in a given direction. 
It does not justify optionality of @pattern.

>Keep the simple case simple

Agreed.  Keep all cases consistent; do not make special cases that will
make it harder to define additional patterns.

>Rules for shortcuts
>Make (input|output)/@messageReference optional and say the direction
>implies the reference because only one in each direction

Make this a general rule for all patterns.  If a pattern contains only
one message in a given direction, then the @messageReference for that
message is optional.

>Say order of input/output significant (as today)
>Make @pattern optional and say its value is computed based on order of
>input/output and whether both or only one is present

No, no, no.  Keep the URI to disambiguate, leave order of operations
insignificant.

The problem with making this shortcut for this particular set of
patterns is that it privileges them so extremely that no other patterns
are reasonably interoperable.  If the rule is: "look at the @pattern",
it's clear.  This proposal says: "look at @pattern, and if it does not
exist, then look at the sequence of messages and choose from a limited
set".  In implementation, it is *guaranteed* that some folks will
entirely ignore @pattern, and use *only* sequence, meaning that it will
not be possible to define additional patterns that have different
semantics from those that we provide shortcuts for.

Under those circumstances, I would argue, we should throw out all the
existing patterns work (as well as attempts to support any networking
paradigm other than the strongly client/server).  I am *very* strongly
opposed to this.

Note that the one thing in the proposal that I am opposed to is making
the @pattern attribute optional.  I agree, in principle or in whole,
with all of Sanjiva's points otherwise.

I'll reiterate: I *strongly* oppose the notion of making @pattern
optional.  I agree with all the rest of Sanjiva's presentation, apart
from the recommendation, based on making @pattern optional, that certain
privileged patterns be recognizable from sequence.  I feel that
providing a more complex algorithm for recognizing the pattern to which
an operation conforms is not a good solution, but I like the syntactic
shortcuts (optionality of @messageReference in both interface and
binding, if the pattern has only one message in a given direction)
otherwise.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 22 September 2003 13:09:42 UTC