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

[Joseph Scott]

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  
> stone?
>
> 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  
> method?


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:

	http://localhost/wp/trunk/wp-app.php/attachment/file/295

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  
> disabled?).
>
> 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 Scott
joseph at josephscott.org
http://josephscott.org/