|
List Info Thread: WD1.1 Service Procedure Description
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
WD1.1 Service Procedure Description |
|
List Info Thread: WD1.1 Service Procedure Description
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Or, is it just 0 and 1?
Tom
--- In json-rpc@yahoogroups.com, "Atif Aziz"
<atif.aziz
...> wrote:
>
> Point taken, Jim. I agree that there may be room for
misunderstanding.
> I'll see what I can do to improve the wording or
discussion around that
> topic. Perhaps a reminder would help.
>
> >>
> a client framework may, for example, count parameters
in a "call",
> compare them with the count of parameters in the
service definition, and
> refuse to process the request if they do not match.
> <<
>
> The client should definitely not be using the Service
Description to
> enforce runtime checks. If it does, then it should be a
configurable
> option that can be relaxed. This is also important for
versioning. If I
> add a parameter later on in a compatible way and the
client is working
> with a proxy against an older description then a
rejection of the call
> at the client could be premature. I might have a safe
default to for the
> new parameter and would have been happy to accept the
call!
>
> >>
> I do not have control over how the specification is
interpreted, nor
> whether the individual creating a client that uses the
data has read the
> entire specification, as you suggest.
> <<
>
> There's always that risk. It's the reason I decided to
discuss Procedure
> Call Parity (6.6) and Call Approximation (6.6.1) way
before getting to
> the Service Description (10). But, certainly, if a
person jumps to
> section 10 of the spec and starts coding away the
client then they might
> cripple their users.
>
> Thanks for your feedback so far and attention to
detail.
>
> -----Original Message-----
> From: json-rpc@yahoogroups.com
[mailto:json-rpc@yahoogroups.com] On
> Behalf Of Jim Washington
> Sent: Thursday, September 07, 2006 2:34 PM
> To: json-rpc@yahoogroups.com
> Subject: Re: [json-rpc] WD1.1 Service Procedure
Description
>
> Atif,
>
> Thank you for the response.
>
> I was just thinking in terms of how the data is likely
to be used.
>
> "system.describe" is a MUST for a conforming
JSON-RPC service. If I am
> writing a client, and the Service Procedure Description
is available, I
> am going to use that data.
>
> In the definition of "params" for Service
Procedure Definition, WD1.1
> states:
> If this member is missing or the Null value then the
procedure does not
> expect any parameters.
>
> A reasonable person may easily interpret that as,
"if there are no
> parameters in the definition, then there are no
parameters". I foresee
> that a client framework may, for example, count
parameters in a "call",
> compare them with the count of parameters in the
service definition, and
>
> refuse to process the request if they do not match.
>
> I do not have control over how the specification is
interpreted, nor
> whether the individual creating a client that uses the
data has read the
>
> entire specification, as you suggest.
>
> I see a problem with the text in this small section of
the draft at the
> moment. I am hoping for clarification so that there are
not
> misunderstandings that may lead to failure of
interoperability in the
> future. It may be a note of clarification, or perhaps
an addition to the
>
> Service Procedure Description as suggested below.
>
> -Jim Washington
> >
> > Sections 6.6 and 6.6.1 are probably more relevant
for this discussion
> > because that's what allows your case of optional
versus required
> > parameters to pass. I think that JSON-RPC should
not get too involved
> > with the optional, required and other language
artifacts. What's more
> > important to define is how the call is encoded by
the client and how
> > it is eventually handled by the server and
section, 6.6.1, "Call
> > Approximation", has that specific purpose. It
defines what happens if
> > parameters are missing:
> >
> > /"If the call supplies fewer parameters than
expected then the missing
>
> > parameters SHOULD assume the Null value."/
> >
> > This should accommodate dynamic languages as well
as use of shorter
> > messages for dense methods. The Service Procedure
Description is quite
>
> > loose because its purpose is not really to define
the rules for calls,
>
> > but rather to help with naming parameters and
generation of reasonable
>
> > proxies for the strong-typed environments. And
independent of the
> > type-strictness of your environment, if the
parameters are named in
> > the description then it helps the client library
to encode a more
> > self-contained and friendlier Procedure Call even
if the call site
> > uses positional parameters. Note also the
suggestion to use Null if
> > the parameter is missing. The use of
"SHOULD" was also intentional so
> > that environments that allow use of default value
substitution can do
> > so without breaking the rules (which would have
been the case had the
> > phrase used "MUST").
> >
> > Do you think this reasonably covers your concern?
If you have
> > parameters then describe them. Their description
does not mandate
> > their use during the call. IOW, the caller will be
at the mercy of the
>
> > server, service and/or the method to decide
whether the call is
> > accepted or rejected (allowing for programmer's
ingenuity).
> >
> >
>
------------------------------------------------------------
------------
> >
> > *From
json-rpc@yahoogroups.com [mailto:json-rpc@yahoogroups.com]
*On
>
> > Behalf Of *Jim Washington
> > *Sent