Re: SOAP-Attachment question -> handling large attachment?

At 03:17 PM 10/8/2001 -0400, Shuo Shen wrote:
>I got this list name from http://www.w3.org/TR/SOAP-attachments. Hope this
>is the right place to ask the question.
>
> From implementation of a SOAP-Attachment request, I have trouble to figure
>out how to allocate resource for the attachment part. We want to scale up
>our apps to deal with attachment of Gig size level (1-100G bytes). Normally,
>we can use either memory or a temporary file to persist the data before
>processing SOAP logic. However, to use memory for 100G data, that's not
>going to work(in today's most application :). We expect SOAP-Attachment
>draft giving us some criteria on this.
>
>Specifically, we suggest about two ways:
>1. Adding a http-like Content-Disposition header to each body part, which
>will have sth like:
>
>--MIME_boundary
>Content-Type: image/tiff
>Content-Transfer-Encoding: base64
>Content-ID: <claim061400a.tiff@claiming-it.com>
>Content-Disposition: attachment-data; name="attachment1";
>filename="foo.tif""
>
>so we know we can persist the following data to a file anyway no matter the
>size;

In my opinion this solution would be inappropriate since it relies
server assumptions about the client.  A 1k file may be "too big" for
some clients; 100G may be "just fine" for another.  Moreover, files
and filenames are artifacts of end point implementation that should not
be exchanged between clients and servers.


>2. Or adding a Content-Length or Attachment-Length header for each body part
>
>--MIME_boundary
>Content-Type: image/tiff
>Content-Transfer-Encoding: base64
>Content-ID: <claim061400a.tiff@claiming-it.com>
>Content-Length: 12345
>
>so we can allocate resources best fit the Content-Length. If it's small,
>into memory(for efficiency); if it's big, into file system(for scale).

As far as I know this solution would be a good one based on the positive
experience that HTTP has had with Content-Length (ok, minus the early days).
However Content-Length is not intrinsically part of MIME as I understand
it.  MIME is designed to allow chunks of data to be moved about, not long
streams prefixed with control data.  HTTP stretched MIME; it seems to have
survived.

>It's not a question on SOAP as a wire protocol, but on how to do it in
>reality. Just like the other thread talking about how to identify the
>SOAP-Attachment's SOAP/XML part, it's important for the implemention.
>
>What do you suggest? Or is there something somebody can put into the
>SOAP-Attachment documentation for this?

I don't believe that this fix should be made in SOAP-Attachments.
Rather the nice solution would be a separate document on Content-Length
for Multipart MIME.  Then SOAP-Attachments could reference it.


>Thanks,
>Shuo

______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Tuesday, 9 October 2001 11:07:12 UTC