|
List Info Thread: 1.1WD: Procedure names with reserved semantics.
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
1.1WD: Procedure names with reserved semantics. |
|
List Info Thread: 1.1WD: Procedure names with reserved semantics.
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
...> wrote:
>
>> By mandating that system.describe must be supported
for a service to be
>> able to say it is JSON-RPC compliant you have
placed onerous
>> implementation requirements on a service provider.
Either an implementer
>> has to be able to detect when access is via a
certain protocol and
>> export different sets of methods for each, or they
will simply have all
>> methods share the same namespace. But then you get
conflicts with the
>> different protocols as for example the XML-RPC
protocol has a suggested
>> set of methods of its own (but not mandatory) for
performing
>> introspection. These methods similarly use a
'system.' prefix.
>
> My assumption is that the protocol handler will
intercept the request
> for system methods and respond to them directly without
ever needing to
> rely on the service to provide the implementation.
Given this, the
> JSON-RPC protocol handler will know how to handle
"system.describe", but
> an XML-RPC protocol handler on the same service will
probably send it
> along to the service. On the other hand, the XML-RPC
protocol handler
> would know how to respond to
"system.listMethods". Is this an
> unrealistic or impractical assumption?
The problem is that the JSON-RPC and XML-RPC protocol
handlers can be on the periphery
only of a much larger messaging system implemented using
some totally distinct
technology. For example, they could be gateways into a
system which uses Corba, IBM
MQSeries etc.
At the gateway where the JSON-RPC/XML-RPC protocols are
being handled, there may be
no knowledge of even service names available let alone what
methods they provide. In
other words, the messaging system the gateway is for may be
largely opaque with only
enough information known so as to be able to inject a
request into the core messaging
system and now it will get to its intended recipient.
Where this is the case, it basically becomes impossible to
implement these JSON-RPC
specific methods where the protocol handlers are implemented
as there is insufficient
information available to return a result.
The only place where the information may be available is the
service itself. One can't
change the core messaging system infrastructure where it
interfaces with a service to
implement it so it falls back to the service to implement
it. But then, asking an
implementer of a service to provide methods to satisfy some
requirement for a protocol
handler they may not even know is being used or care about
isn't going to practical.
Thus, if you see this as being used to interface into lots
of different types of application
infrastructures, potentially using quite distinct messaging
technology, I can't see how you
can avoid saying that supporting the methods is anything but
optional. If you do still make
it mandatory, then where people are bridging into these much
larger systems, they will
simply ignore the requirement and they will not be
conforming.
What I might suggest as a possible compromise is that you
explicitly say that if a server
application cannot implement the methods is that they return
a specific type of error to
indicate it. Whether this be a HTTP level not implemented
status, or whether you add
another error status within your JSON-RPC error set would be
up to you.
The only problem with this is those JSON-RPC client
implementers who think it is a good
idea to use system.describe to automagically create a
registered sets of methods within
the Javascript class held by the browser. I hope that this
automagic way of doing things
isn't going to be seen as the default/only way of doing
things. :-(
Having had more time to think about some other aspects of
the specification as well, there
are other areas where mandatory requirements aren't
necessarily going to be practical
when JSON-RPC is only a gateway into a large system. Another
example is the use of
dictionary style mappings to access into a system which is
only able to support positional
parameters. Trying to implement a mapping from a dictionary
style request where the key
names are ASCII representation of integer number
representing the position to an array
could be more trouble than not depending on the system.
Because positional parameters
will work okay, a system which only supports positional
parameters should like above be
simply able to say that dictionary style access is not
implemented and indicate this as such
using a distinct error type.
In all, what you end up with is rather than systems that
don't comply, is systems being
able to indicate their feature set by noting when things
aren't implemented.
>> it is generally impossible or impractical to
implement such service
>> level requirements which are dictated by a
protocol.
>
> Yes, the specification does place this requirement on
the service, but
> it does not say how that requirement needs to be
implemented. It's
> really a logical requirement.
Yes, but the point I was trying to make elsewhere is whether
the specification should even
state such requirements given that they are an application
level, rather than protocol level
feature. In other words, your specification tries to span
multiple layers in what would be
seen as a OSI network stack. This is generally a bad idea.
You should separate application
level stuff into a separate specification and use of the
protocol should not require one to
implement the separate application level specification.
Graham
Yahoo! Groups Links
<*> To visit your group on the web, go to: