User extension mechanism for XML-RPC.
Written: 2004-01-16 By Brendan G Bohannon (aka: cr88192).
The purpose of this is to allow possibly preserving implementation or extension
specific semantics or features in a general way, falling back to the core
protocol if it is not possible to preserve such features.
An example I will give is a lisp style typesystem. Though it is possible
to drop all language specific semantics and use general primitive types, in
no way is this desirable (it makes an ugly mess of otherwise clean data).
This is especially true in the case where both ends use the same typesystem,
thus transmission involved semantic loss should be minimalized.
For a given set of point to point communications, it is assumed that some
info is kept on one end about the other (eg: a set of known namespaces) or
otherwise preserved features. This can be used for one end of the link to
generally decide how and what data to represent, falling back to the basic
protocol if it is not possible to send anything of real use...
The purpose of the system.listExtensionNamespaces function is for retrieving
a namespace list, where the idea is that each namespace gives some context
as to features supported by the other end. Unknown namespaces have no implied
meaning, so are simply ignored.
I believe that 2 major sets of extensions is needed here:
Typesystem extensions, needed for preserving specialized semantics for a
language or implementation;
Message extensions, used for representing messages specific to an implementation
The general assumption is that outside the scope of the implementations
using an extension, quite likely the extension is irrelevant anyways (this
should not add any real cost to the general protocol).
I believe that if possible extensions (or extensibility) should avoid putting
too much weight or complexity on the core protocol (I will point at soap wrt
this). The core protocol should remain small and not have to worry about the
exact complexities or special cases of the various implementations...
Gets a list of extension namespaces, returned as an array of strings.
If not supported the implementation will return a fault, otherwise it will
return a list of extension namespaces.
Returns a list of tags supported by a given namespace.
Some special forms are usable (enabled by such extensions):
<value xmlns=.../>, where ... is the namespace name.
This is used for adding new user types.
<message xmlns=.../>, useful for adding new toplevel message types.
BGB Extension 1: Scheme Like Typesystem
BGB Extension 2: A Few Misc Types