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

 Shuo,
 I think the right approach to possibly infinite data (as is the
case of MIME Attachments in SOAP) is always to stream the data to
the application, make available every metainformation we've got
(like content disposition or length) and let the application do
what it will.
 For example all our SOAP implementations do it exactly this way.
 The application, when it gets the stream, can choose any of the
following or something completely different:
 1) read all the stream into memory,
 2) write all the stream onto filesystem,
 3) do some of the above with a limit on maximal size,
 4) process the data on-the-fly and produce a limited-size
result,
 5) process the data on-the-fly and produce an output stream with
the (possibly infinite) output.
 Best regards,

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/



On Mon, 8 Oct 2001, 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;
 >
 > 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).
 >
 > 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?
 >
 > Thanks,
 > Shuo
 >

Received on Wednesday, 10 October 2001 11:09:26 UTC