[wp-xmlrpc] what clients send an XML declaration in XML-RPC requests?
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
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 at josephscott.org
More information about the wp-xmlrpc