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

A recent IETF Internet Draft packaging proposal provides even more
flexibility in streaming content than what is currently provided by MIME
Multipart/related (the approach taken by SOAP with Attachments). It's called
MIME Application/Multiplexed
(http://search.ietf.org/internet-drafts/draft-herriot-application-multiplexe
d-03.txt) and it allows binary content to be interleaved with the main XML
document. 

A typical application is an XML document containing images, sent to a small
printing device. The image attachments can be interleaved with the main XML
document contents in such a way that the images belonging to a particular
page can be streamed next to the XML content for that page. That way the
printing device does not need to absorb more streamed material than the
amount required to render a single page. After that page is done, resources
to process the page can be released and streaming can be resumed for the
next page, and so on.

MIME Application/Multiplexed was recently adopted by UPnP.

Ugo Corda
Xerox Research & Technology

-----Original Message-----
From: Jacek Kopecky [mailto:jacek@idoox.com]
Sent: Wednesday, October 10, 2001 8:09 AM
To: Shuo Shen
Cc: 'xml-dist-app@w3.org'
Subject: 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 14:29:57 UTC