[wp-xmlrpc] Re: metaWeblog.getCategories, not returning struct of structs, problem?

[Joseph Scott]

On Nov 9, 2007, at 8:44 AM, Dougal Campbell wrote:

> I'm willing to bet that this is just a case where the vagueness of the
> spec (and lack of good examples) caused us to mis-implement. The
> category portion of the post struct is an array, so it probably seemed
> natural that getCategories should, as well.

Agreed, and that might be why Six Apart doesn't implement it (or at  
least doesn't document that they do: http://www.sixapart.com/ 
developers/xmlrpc/metaweblog_api/).

As Joe mentioned it seems most others provide an array of structs  
except for TextPattern, http://txp.kusor.com/rpc-api/ 
metawebloggetcategories.  But they don't indicate what they use for  
the index name of each struct.

Windows Live Spaces indicates they return an array of structs, http:// 
msdn2.microsoft.com/en-us/library/aa905667.aspx.

> I suggest that we try converting to a struct, and test the major  
> clients
> against it to see if anything breaks. If everything still works,  
> then we
> fix it, otherwise, it probably needs to be a 'wontfix'.

I'm inclined not to fix it at this point.  Mostly because it seems  
that in the absence of concrete examples in the spec most vendors  
have decided on an array of structs instead.

That said I would be willing to sort of fix it in a different way.   
Add a fourth parameter to metaWeblog.getCategories that would  
indicate that we should return data struct of structs just like the  
spec says.  Call it strict_mode or something and it would be a  
boolean and completely optional.  If it is set to true then we adhere  
to the spec, if it is set to false, any other value, or not set at  
all then we do things as they currently stand.

Given the history and circumstances I believe this approach has the  
most upsides with the fewest down sides.

> So, the question is, what is the 'name' portion of the parent struct
> going to be? The category name, category slug, or category ID? I'm
> leaning towards slug, especially since we already have the ID and name
> in the data portion of the struct. However, I'm guessing that the
> original intent was to use the category name as the key. Other
> considerations to think about: the spec obviously assumes a flat
> category space, but we have hierarchical. Should we try to account for
> that? I know we're already sending extra info about that in the data
> portion of the category structs, but that's not part of the spec  
> either,
> and we want to be able to handle naive clients.

As for the name portion of the parent struct I think there are really  
only two reasonable potential options: the category id or the slug.   
Both of those are guaranteed to be unique.  The category name isn't a  
good option because you can have duplicates.  While there might be  
nothing technically wrong with having dups I suspect there is at  
least one XML-RPC library out there that will fold dups down into  
one.  My initial reaction would be to use the category id, but I  
could potentially seem some client library munging that as well (just  
numbers, out of sequence).  That leaves the category slug, which I'd  
be fine with.

Exposing category hierarchies, if a client wants to get that  
information then they should make use of the already available non- 
spec parentId field.

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