Re: Proposal for cleanup of RPC section (issue 195)

Now I'm confused :-( Comments inline.

Jacek Kopecky wrote:

>The second part of my proposal is more radical in that it
>simplifies the model of a procedure by removing the in/out
>parameters and return value terms.
>
This is the bit I don't understand. Here you say removing the return 
value term. From your original mail you say the same

> 2) remove the term "return value" altogether: 


but...

>Currently a message is able to say whether there is a return 
>value and what arguments are present (for the struct case) and 
>the spec is unclear (if not broken) for the array case.
>
Broken is also the term I would use.

>
> The first part of my proposed rewrite keeps it the same for the
>struct case and makes it clear that there is no distinction
>between a return value and an out parameter in the array case
>
... but I must be reading this wrong. It seems to me that you were 
saying to remove the term "return value" which would also remove the use 
of the FQ name for the return value (you can't call it ...:return if you 
are not allowed to say it's the return value?)

>
>(because in my optinion there really *is no distinction* between
>a return value and positional out parameters - they both don't
>have a name and it doesn't really matter whether you start
>counting the parameters from 0 or from 1). So effectively, this
>first part of my proposal has no notion of a return value.
>
That's arrays only. The same logic does not apply to structs which use 
name instead of position.

>
> The full proposal goes further - removing in/out parameters 
>and the return value altogether. Now let me explain why I 
>don't think we're losing anything:
> IMHO the notion of in/out parameters need not be in the protocol
>since we don't have the explicit model of a procedure and a
>
>
>in/out parameter in fact means one value going there and one
>going back. When the parameter is named, they probably share the
>name. In any case, only the language bindings are concerned with 
>this and we cannot help them here. Not every language supports 
>in/out params.
> With return values it's a little more complex. It's already not
>really there in the array case so let me only think about the
>named parameters case. If we want a struct (as opposed to
>multistructs which IMO would be dirtier to spec out) we have to
>give a name to the return value. Currently we give it the full 
>name but many people complain this doesn't really play well with 
>XML Schema, which is true but which I don't think should concern 
>us at all. 
>
This is what is confusing me. This paragraph and the following imply you 
are suggesting keeping the naming of the return value but the original 
mail, from my reading, was saying to remove the specific name. I must be 
misunderstanding one or the other. The following paragraph from the 
original mail is basically saying 'call the return value anything you 
want' is it not?

>  3) add a note somewhere which says: "Note: many languages have
>the notion of a return value - an unnamed [out] parameter. Such
>can be dealt with by inventing a name like 'result' or using the
>array serialization of RPC result. Also some languages have
>[in/out] parameters which can be dealt with as couples of [in]
>and [out] parameters in SOAP RPC. None of this affects
>interoperability."

>
> There were proposals to only specify the local name (but the
>possibility of various conflicts arises here which would have to
>be solved in the language bindings).
> There were proposals to keep the name in the application domain, 
>which is exactly what I've done in my full proposal.
>
So who defines this name? Is it defined by the person writing the 
service? How does my code generator know that this is the return value 
and give the generated method the signature intended by the service 
author? Does that not matter (does it matter if it is generated as a 
return value or an OUT parameter?). It think it IS important to be able 
to identify the intended return value. If for no other reason than 
consistency. I don't want to be on a project that requires clients in 
java and .NET (to pick but 2) and one generates a client with a return 
value and the other generates, from the same definition, a method with 
no return value and a single OUT parameter.

>
> I think either way (only first part or the full proposal) is an
>improvement over the current state, with the second part only
>going further in the direction of the first part. The first part 
>will not solve the issue 195, but that can be solved by saying 
>"we think mandating the full ns-qualified name is better than 
>only mandating the local name", please see my subsequent email on 
>this (it will have the subject "Issue 195: why not only specify 
>the local part" or something alike).
>
I have no argument with using a fully qualified name. I think that makes 
a lot of sense. I'm not actually sure what you are arguing any more 
putting these 2 mails together (I'm tired so maybe a reread of it 
tomorrow will help). Perhaps you could provide an example of what you 
mean for the java methods (i.e. what would the difference in their 
description or wire representation be?).

   void doSomething( OUT int value )

and
 
   int doSomething()

I am coming at this from an implementor's point of view rather than the 
higher level that most will  be looking at it from, and a fixed name 
makes a lot of sense to me. To this end I would agree that your term 
'broken' describes the array representation case, and I am still 
struggling to see why there are 2 representations in the first place?

Pete

Received on Tuesday, 16 April 2002 08:13:15 UTC