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

Brandon Turner bturner at microsoft.com
Sun Jul 26 04:53:02 UTC 2009

If you plan to allow clients to upload images through newMediaObject using a zip file you should expand the scope to allow multiple images to be inside of the zip file.  I don't know exactly how one would have to change the request to specific metadata(names mostly?) for all the images inside of the zip, but I am sure something clever could be thought up.  At least with Writer it is common for us to upload two of every picture, one of the inline image and one of the 'click through' image.  Consolidating those into one request would save considerably more than the savings you would get from optimizing single requests.

None the less, your approach of zip file does seem like a good idea, YouTube has done the same thing with uploading videos through their API.


-----Original Message-----
From: wp-xmlrpc-bounces at lists.automattic.com [mailto:wp-xmlrpc-bounces at lists.automattic.com] On Behalf Of Joseph Scott
Sent: Saturday, July 25, 2009 9:09 PM
To: wp-xmlrpc at lists.automattic.com
Subject: Re: [wp-xmlrpc] what clients send an XML declaration in XML-RPC requests?

On Jul 25, 2009, at 10:17 AM, Daniel Jalkut wrote:

> Hi Joseph - MarsEdit does include the preamble and it looks like your 
> example but also includes content-encoding information:
> <?xml version="1.0" encoding="utf-8"?>
> Is there some context for why you're asking about this? Just curious 
> if we can help brainstorm an answer to whatever is on your mind.

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.  So I've been making calls to  
metaWeblog.newMediaObject with a 3369029 byte jpg file to upload.  The  
nature of base64 encoding adds about a third to the size of the  
original data and processing it takes even more memory.

The XML-RPC library that WordPress uses has a regular expression (a  
preg_replace call) to look for this XML-RPC declaration and remove  
it.  By replacing this regular expression with a simple string  
substitution (with the substr function) I was able to cut the peak  
memory usage of the request by 5.4%.  By decoding the base64 in chunks  
instead of all at once I was able to shave another 1.4% off that.   
When using both of these techniques the total reduction in memory  
usage when compared to the current approach is 7.8%.  These numbers  
are based only on my sample jpg file, I'm not sure yet how much they  
will fluctuate when the data is smaller or larger.

Since I couldn't be sure that the substr approach would work in all  
cases it falls back to the original regex method if the substr can't  
be used.  To determine if the substr method will work I'm checking to  
see if the string '<?xml version="1.0"?>' is at position zero in the  
XML-RPC request.  If it is then use substr, if not use preg_replace.   
This is a very simple approach, would could be expanded upon to match  
other XML declarations.

This got me to wondering how many client requests actually use exactly  
'<?xml version="1.0"?>'.  I plan to do some logging of XML-RPC  
requests on WordPress.com to see what's actually being sent.  But it's  
helpful to get an idea of what those declarations could look like as  
well from client authors.  Brandon's reply about what most .Net apps  
would probably do was helpful to know.

On a slightly related note I've wondered about the idea of compressed  
base64 encoding.  Using my jpg example, a client would zip the jpg  
file, then base64 encode the zipped version and ship that in the XML- 
RPC request.  On the server end we'd base64 decode and then decompress  
the resulting data to get back to the original jpg.  Making the flow  
look like:

jpg -> gzip -> base64  --------> XML-RPC ---------> base64 decode ->  
unzip -> jpg

Setting aside the XML-RPC layer issues for a moment, I don't know if  
this method would really improve things.  It's currently only a  
thought, I haven't run any tests using that approach.

Joseph Scott
joseph at josephscott.org

wp-xmlrpc mailing list
wp-xmlrpc at lists.automattic.com

More information about the wp-xmlrpc mailing list