[wp-xmlrpc] what clients send an XML declaration in XML-RPC requests?
joseph at josephscott.org
Mon Jul 27 13:25:23 UTC 2009
On Jul 26, 2009, at 7:43 AM, Daniel Jalkut wrote:
> Hi Joseph - thanks for sharing your intentions:
> On Jul 26, 2009, at 12:08am, Joseph Scott wrote:
>> I've been looking at PHP memory usage during XML-RPC requests
>> (using memory_get_peak_usage function). With a specific target of
>> reducing the memory usage for large requests, like those with
>> massive base64 encoded data sections.
> A noble effort. But maybe it's like trying to squeeze juice out of a
> Here's another idea, going back to a notion I had a long time ago to
> provide some "cross-API" interoperability between the Atom and
> XMLRPC implementations.
> What if savvy clients were able to use the AtomPub PUT based media
> uploader, knowing that they will get back a URL that is equivalent
> to the URL that they would have gotten using the newMediaObject
Would returning the "id" for the newly uploaded file be enough? Right
now we send the following information back: file, url and type. The
url field is the actual URL for the file. Which corresponds to the
<content> item in an AtomPub request for a specific attachment.
What's a little awkward is that the file is also available via the
<link rel="edit-media"> item. I understand that <link rel="edit-
media"> is also used to update the attachment, but it still feels
strange to have AtomPub send back a response that provides two
different ways to access the same exact resource.
At any rate, edit-media URLs look like:
In WordPress upload information is stored in the posts table with a
post_type of attachment. That 295 on the end is the ID field from the
posts table. The ID for that item will be the same then no matter how
it is referenced. So if we make wp.newMediaObject return: file, url,
type and id then that id value could be used to determine the AtomPub
URL for that uploaded file.
I wouldn't categorize this as particular smooth since there's no exact
corresponding id field in AtomPub requests that would make it easy to
match with. But it would work and would be consistent, with a strong
likely hood of not being changed in the future.
> I'm sure where would be details to work out (e.g. does XMLRPC just
> expose its own "AtomPub-like" PUT method, since AtomPub might be
> But the gist of this feedback is, can we focus on providing clients
> a clean exit from the memory limitations of the newMediaObject
> method, instead of just shaving a few % off the call's impact?
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.
> Image uploading is one of the areas where the AtomPub implementation
> currently blows the XMLRPC implementation out of the water. I might
> prefer to use the AtomPub mechanism for uploading if I could count
> on it being available to me.
Agree 100%, being able to just push the binary bits across the wire is
a much nicer way to upload files.
As for counting on it being available, what did you have in mind?
AtomPub support has to be turned on in the same way that XML-RPC
support does. And you get a similar sort of message if you make an
AtomPub request when it is not turned on:
AtomPub services are disabled on this blog. An admin user can enable
them at http://localhost/wp/trunk/wp-admin/options-writing.php
joseph at josephscott.org
More information about the wp-xmlrpc