Re: some initial attachment requirements

Mark,

   This is a good start.  Some suggestions and comments:

I would like to see one addition to your list:

  0. The representation should aid debugging with simple tools.

This is one of the most powerful reasons we are talking about XML messaging
rather than binary messaging. Throwing this advantage out at the packaging 
layer
makes no sense.

     -- The specification should allow the sending XML application to 
determine
the part identifier.  This allows SOAP messages to be ROMed for embedded
systems.  Its a bit hard to write this down because many people assume that
the top of the stack is TCP, meaning that XML application is everything else.
In practice the packaging software layers between the XML application and
TCP, which is why we can talk about attachments separate from XML.  The
spec needs to recognize this split and allow the XML application to determine
the URI.

   -- Performance analysis should assume modern hardware.  Thus CPUs are
fast and memory is cheap, but I/O transfers are slow and multiprocessing 
common.
The specification needs to concentrate on how "large" messages (MB and GB) are
handled.  Optimizing the packaging of small messages will make no difference
since setup and context switching latency will dominate over 
unpacking.  (Actual
measurements would be a great asset here.)

   -- I would urge the consideration of a MIME-receivable but fixed format 
ASCII
encoded specification with part sizes preceding parts.  This allows the 
receiver
to unpack the message without dynamic memory allocation but keeps the headers
in text.


At 03:52 PM 1/3/2003 -0500, Mark Jones wrote:

>Here's a stab at some initial requirements for the concrete attachment
>spec(s).  These are far from comprehensive I'm sure and may need some
>tweaking, but hopefully it will get us going.
>
>--mark
>
>Mark A. Jones
>AT&T Labs -- Strategic Standards Division
>Shannon Laboratory
>Room 2A02
>180 Park Ave.
>Florham Park, NJ  07932-0971
>
>email: jones@research.att.com
>phone: (973) 360-8326
>   fax: (973) 236-6453
>
>================================================================
>
>SOAP Attachment Specification Requirements
>
>Representation
>
>1. The specification must define a means to carry multiple data parts.
>
>2. The specification must define a means for parts to carry
>    arbitrary data, including non-XML data (e.g., binary data and XML
>    fragments).
>
>3. The specification must admit a reasonably time-efficient
>    means of identifying parts.
>
>4. The specification must use a reasonably space-efficient
>    representation.
>
>5. The representation must efficiently support the addition and
>    deletion of parts.
>
>
>Reference to Parts
>
>6. The specification must permit parts to be identified by URIs.
>
>7. The URI identification scheme must be robust under the addition and
>    deletion of parts -- i.e., it must not require that URIs to other
>    parts be altered, it must be relatively easy to avoid URI
>    conflicts, etc.

______________________________________________________
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 Monday, 6 January 2003 12:54:22 UTC