[wp-xmlrpc] Wordpress version from xmlrpc?

[Joe Cheng]

I might find this useful, if both version number and the fact that it is WordPress are both provided. The only reason I'm not more excited is because this information can currently be gleaned from the homepage metadata and the RSD.

Personally, I'd actually be more interested in having version information in the RSD.

-----Original Message-----
From: wp-xmlrpc-bounces at lists.automattic.com [mailto:wp-xmlrpc-bounces at lists.automattic.com] On Behalf Of Joseph Scott
Sent: Sunday, January 13, 2008 2:18 PM
To: wp-xmlrpc at lists.automattic.com
Subject: Re: [wp-xmlrpc] Wordpress version from xmlrpc?


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/


_______________________________________________
wp-xmlrpc mailing list
wp-xmlrpc at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-xmlrpc