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

[Daniel Jalkut]

Hi Joseph -

On Jul 27, 2009, at 9:25am, Joseph Scott 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.

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 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.

> 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).

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?

Daniel