Hi all!
As I just noticed, no one has yet posted the struct approach, for
beeing able to look up wether a implementation supports a given
capability - as Charles and me have already textually described it,
I'll first try to formalise this ;) Afterwards some more thoughts.
so here's a RFC:
struct system.getCapabilities()
retval:
struct {
"specId1" => struct {
"specUrl" => string,
"specVersion" => integer
}
"specId2" => struct {
"specUrl" => string,
"specVersion" => integer
}
...
}
in XML (example):
<struct>
<member>
<name>xmlrpc</name>
<value>
<struct>
<member>
<name>specUrl</name>
<value><string>http://www.xmlrpc.com/spec</string></value>
</member>
<member>
<name>specVersion</name>
<value><int>1</int></value>
</member>
</struct>
</value>
</member>
<member>
<name>introspect</name>
<value>
<struct>
<member>
<name>specUrl</name>
<value><string>http://xmlrpc.usefulinc.com/doc/reserved.html</string></value>
</member>
<member>
<name>specVersion</name>
<value><int>1</int></value>
</member>
</struct>
</value>
</member>
<member>
<name>faultCodes</name>
<value>
<struct>
<member>
<name>specUrl</name>
<value><string>http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php</stri\
ng></value>
</member>
<member>
<name>specVersion</name>
<value><int>3</int></value>
</member>
</struct>
</value>
</member>
</struct>
Some more thoughts:
This does not allow a client to distinguish between specs not
supported and not up-to-date capabilities structs. On the other hand a
server-maintainer ist not able to explicitly state that 'we do _not_
support this spec.'
This is a minor point, and I don't know wether it makes sense to add
more complexity to the approach stated above, just to fix that. One
solution could be to allow to 'values' vor the spec-structs. If the
value is a bool, it must be false and it is explicitly stated that
this spec is _not_ supported. If the value is a struct, it follows the
above described behaviour. Would the dynamic structs eventually raise
a problem for some implementations?
Does that make any sense anyway?
(Btw, I noticed that Dan's and my approaches are absolutely identical,
except of the int/float thing. Funny stuff ... :)
--
Best regards,
Andreas mailto:andreas.bolka@...