Re: DIME Use Case?

On Sun, 14 Apr 2002 08:28:48 -0700, in soap you wrote:

>David Buksbaum <[email protected]> writes:
>> We did do performance analysis against SOAP over HTTP and SOAP over
>> SMTP. In both cases, we were able to get a significant performance boost
>> with SOAP over DIME. The are where the gains were made had little to do
>> with MIME though. They had to do with connection startup and
>> handshaking, and pulling the block off the wire on the other side.
>>
>> Some of the benefits of DIME is that it is not request response. It is a
>> simple packet that encapsulates data. HTTP is request response, and the
>> direction of data is often fixed. Using SOAP over DIME allowed us to do
>> request, response, and events over the same pipe without any 'tricks' or
>> complexity.
>There seems to me to be some layer confusion here: DIME is a packaging
>format, not a transport protocol. HTTP and SMTP are transport protocols.
>It sounds like you've invented (but not completely specified) some
>simple transport protocol of the form of: open up a TCP channel and
>shove DIME messages down it and let the upper level application
>worry about the semantics. True?

There's a SOAP/DIME/TCP binding specified in the WS-Routing spec.

>It would be nearly as straightforward to define and implement an
>analagous protocol with MIME replacing DIME. Again, what value is
>DIME adding to the picture?
>
>-Ekr

Simplicity of implementation, performance. No one has defined a subset
or profile of MIME which gets anywhere near the simplicity of DIME.
[SwA is the what most SOAP people look at for MIME based attachments,
and it doesn't place many restrictions on what parts of MIME to use]
In particular boundary management in MIME is a PIA, AIUI the boundary
searching can be simplified by the use of a content-length header in
the part, but then what's the MIME equivalent of chunking ?

Cheers
Simon
www.pocketsoap.com