Search the web
Sign In
New User? Sign Up
xml-rpc · XML-RPC Discussion
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Real people. Real stories. See how Yahoo! Groups impacts members worldwide.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
system.getCapabilities   Message List  
Reply | Forward Message #2897 of 6839 |
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@...




Mon May 14, 2001 2:37 pm

andreas.bolka@...
Send Email Send Email

Forward
Message #2897 of 6839 |
Expand Messages Author Sort by Date

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...
Andreas Bolka
andreas.bolka@...
Send Email
May 14, 2001
2:37 pm

Hi, Wha is the current status of XML-RPC after SOAP is published?, Is XML RPC going to be special application of SOAP? thanks - Unmesh ...
unmesh joshi
unmesh_joshi@...
Send Email
May 15, 2001
9:03 pm
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help