Re: DIME Use Case?

David Buksbaum <[email protected]> Sun, 14 Apr 2002 11:14:54 -0400
Newsgroups gmane.comp.windows.devel.dime
Message-ID <000801c1e3c7$2509f090$6401a8c0@scrooge>
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.

As far as not implementing the chunked protocol, it is not much more
difficult to do. Some others that I have given the code do have added
it. We did not. It would not take much effort, but it serves no purpose
for us at this time so we wont do it yet. Someday we will.

>From my point of view, DIME is a replacement for HTTP and SMTP more so
than for MIME. If I remember the spec correctly, DIME was designed with
transporting MIME types, so I am not sure where the DIME vs. MIME has
come up from. We don't use MIME because we don't need it, not because
DIME was faster or better. We use DIME because it was faster and easier
than HTTP and SMTP.

David

-----Original Message-----
From: Discussion of DIME technology [mailto:[email protected]] On
Behalf Of Eric Rescorla
Sent: Sunday, April 14, 2002 10:57 AM
To: [email protected]
Subject: Re: [DIME] DIME Use Case?


David Buksbaum <[email protected]> writes:
> Bottom line is that it was easy to implement, it is fast (relative to
> other wire schemes),
Hmm... Define "fast". Have you done any performance analysis, comparing
it to alternatives?

> One caveat is that we did not implement the chunking protocol yet
> since our payload sizes are somewhat small.
It's almost always easy to hack up some custom protocol for a small
application. When one is designing a standard protocol for general use,
things rapidly become more complicated.

I'm not saying that MIME couldn't be simpler--it could be. However, what
I don't believe is that by the time you've produced a sufficiently
complete version of DIME that it can displace MIME entirely (even for
the limited environment in which you envision deploying DIME) the it
will be sufficiently simpler than MIME to justify the additional
specification effort.

-Ekr

--
[Eric Rescorla                                   [email protected]]
                http://www.rtfm.com/