<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> will import/export of multiple formats be embedded in the mime<br>> encoding of the incoming asset creation request?
<br><br>That's a good question.  I think that until we firm up on at least one<br>official format (which is probably post 0.5) the question is sort of<br>moot.  I think it's a good thing to think about though.<br>
<br></blockquote></div><br>Currently we don't use MIME, and I have not seen an example of a REST web service using mime. Of course that doesn't prevent us from using MIME, I would not advocate using MIME as a transport format.
<br><br>Currently the assets server ships all data as "application/xml", and the binary information is converted to base 64 encoding. I would suggest we stay with this format, with but a few modifications. The primary change I would suggest is to handle the fact that base 64 is a pretty inefficient format to use when transporting binary information, especially considering that HTTP is a 8 bit per byte protocol. I would suggets that when assets exceeds a certain size - which needs to be determined experimentally - we gzip the xml data, and transmit raw binary information in the HTTP body.
<br><br>I.e. when assets size is less  than some cutoff we ship "application/xml", otherwise we ship "application/gzip+xml".<br><br>Unfortunately the mono implementation of GZipStream is buggy, so we cannot use that, the only other native implementation of GZip I have found is GPL with a pretty confusing FLOSS exception (Adam doesn't like it). This means that this compression feature must wait until we either:
<br><br>a) Find a better gzip implentation<br>b) The mono GZipStream patch gets into common usage<br>c) we implement our own gzip stream.<br><br>/tleiades<br>