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

[Joseph Scott]

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
http://josephscott.org/