[wp-xmlrpc] what clients send an XML declaration in XML-RPC requests?

Joseph Scott joseph at josephscott.org
Mon Jul 27 15:45:56 UTC 2009

On Jul 27, 2009, at 7:45 AM, Daniel Jalkut wrote:

>> Would returning the "id" for the newly uploaded file be enough?   
>> Right now we send the following information back: file, url and type.
> Hmm, I hadn't considered augmenting the response from  
> newMediaObject.  I was thinking more along the lines of just  
> providing a means of knowing that the AtomPub interface was  
> available. But I guess the RSD does that already.  Maybe I should  
> just stop being so worried and aggressively use the AtomPub based  
> uploader if it exists, and assume that if it succeeds, the resulting  
> image URL is as good as the one I would have gotten from  
> newMediaObject.

If you request wp-app.php/service from a WP blog and the response has  
an HTTP 403 Forbidden response then AtomPub isn't enabled on the  
blog.  You also won't get back an XML document, you'll get a plain  
text message telling you AtomPub isn't enabled.  When it is enabled  
you get HTTP 200 OK response.

I suppose you could loop through the src attribute of the <content>  
element looking for the same URL that the *.newMediaObject XML-RPC  
response provided.  Same basic technique that would need to do to  
match the ID.

> While I do think it would be cool to provide some extra information  
> in the newMediaObject call, I wonder if it would break some  
> clients.  MarsEdit wouldn't have a problem but I can imagine some  
> clients are hardcoded to expect only the rigid values that are  
> currently returned.

We've added fields to XML-RPC responses and not had any complaints  
that it broke clients.  Now that I've said that I expect to get an  
email in the 48 hours complaining of this very thing :-)

>> We can do that.  And if I can shave off more than 7% in memory  
>> usage by changing a few lines for the code path that the vast  
>> majority of clients are using I don't see any harm in doing that too.
> Definitely. I didn't mean to disparage your work on this. I can see  
> how my comments about squeezing juice from a stone might have been  
> too negative.

No problem, I rely on you to help keep me grounded :-)

>> Agree 100%, being able to just push the binary bits across the wire  
>> is a much nicer way to upload files.
> Here's an idea for the longer term: what about adding a new  
> wp.uploadFiles method.  This could clearly document additional  
> return values alluded to above, and accept multiple files at once  
> (possibly in the zip encoding mentioned by Brandon, or possibly just  
> as an array of Base64 elements).

Having real XML-RPC management methods for media would be a good  
start.  Right now just having the *.newMediaObject methods is  
extremely primitive.  A simple model to follow would be what we've  
done for comments.

> But more radically, what do you think about this proposed  
> wp.uploadFiles() method having too modes for supplying parameters,  
> based on the Content-Type declared by the POST'er?  If the POST has  
> a content-type of "multipart/form-data", then the parameters could  
> be expressed as unencoded binary, otherwise the content would be  
> assumed to be XML.
> I realize this is future-talk brainstorming, but I thought I would  
> mention the idea.  What do other client devs think about something  
> like this? Too confusing to depart from the XML?

I'd be tempted to make the method indicated as part of the URL,  
something like xmlrpc.php?method=wp.uploadFiles.  Since XML-RPC has to  
parse the body of the request to determine what method(s) is being  
called.  This is all definitely future talk.

Joseph Scott
joseph at josephscott.org

More information about the wp-xmlrpc mailing list