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

At 03:09 PM 10/9/2001 -0400, Shuo Shen wrote:
>John,
>
>Thanks for the reply. I did a little bit more research and got different
>opinions.
>
>Your explaination on Content-Disposition seems focusing on SOAP message
>processing. If not, as being explained in
>http://www.ietf.org/rfc/rfc2183.txt, 2.9 specifies this header is optional
>in multipart body part which helps the presentation of the multipart. So
>it's all right as an optional multipart body part header, right? The server
>can choose use it or not.

Sure it is alright, but being optional is not the same as being optimal ;-).
Use Content-Disposition to indicate which part of a multipart is for the
printer vs the browser.  Don't use it to force clients to allocate files.
Let clients work out how to deal with large representations; it's their
job.


>Thanks,
>Shuo
>
> > -----Original Message-----
> > From: John J. Barton [mailto:John_Barton@hpl.hp.com]
> > Sent: Tuesday, October 09, 2001 11:07 AM
> > To: Shuo Shen; 'xml-dist-app@w3.org'
> > Subject: 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
> >

______________________________________________________
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 17:58:32 UTC