[wp-xmlrpc] Wordpress version from xmlrpc?

[Joseph Scott]

On Jan 13, 2008, at 7:54 AM, Kimmo Suominen wrote:

> Shouldn't clients just use system.listMethods to discover available
> methods (i.e. supported features)?  This way the client can choose
> the methods it likes best, and can avoid using ones that are not
> available.


To discover which methods are available, yes, system.listMethods is  
fine.  The details it provides though aren't fine grained enough to  
determine what capabilities and fixes each of those methods have.   
For instance, we've extended metaWeblog.newPost in different ways.   
Right now we don't have a way for clients to know if a particular  
WordPress install has those new features or not.


> Using hard-coded knowledge on the client end would prevent using new
> methods added on-the-fly or e.g. by backporting features to an older
> version of WordPress.


In an ideal world that would be true.  In working with various client  
software though, I found that they are already having to work around  
specific bugs/issues in server side software.  Most/many/all of these  
issues are likely only documented in the software themselves, at  
least I haven't seen a public source of details on how to work around  
problems with each API and specific implementations of each API.   My  
hope with providing some sort of API version is that at least we'll  
be able to address these issues out in the open.

There are client authors on this list who would be able to comment in  
greater detail in that regard.


> Exposing a single API revision number is practically equivalent to
> exposing the WordPress version number.  I'd rather not disclose
> information like that when not necessary.  Software version numbers
> should not be relevant to the network protocols.


I'd tend to agree, which is one of the reasons I was going to put  
together a ticket+patch so that there would be a place to gather more  
feedback.  When I get that submitted I'll be sure to send an email  
out on this list providing a pointer to it.  At this point since I  
haven't even provided one single bit of code for this feature I think  
it is too early to try and dive too deep into the specific issues.


> Having each method somehow support multiple versions of a protocol
> (e.g. different calling conventions) seems complicated.  Clients
> probably wouldn't know how to check for a WordPress-specific API
> revision for each method.  It would be better to extend methods
> in a backwards compatible way, e.g. using named arguments in an
> array.  If backwards compatibility cannot be maintained in a method,
> it probably means it should become a new method instead.


This isn't about backwards compatibility, it is about providing a way  
for clients to learn that a WordPress install supports additional  
features beyond the baseline that we've been living with for years.


--
Joseph Scott
http://joseph.randomnetworks.com/