Re: DIME Use Case?

Just to throw my .02 cents in.

I have implemented a customized remoting framework in .NET using DIME as
my wire protocol. The clients are .NET, C++/MFC, and Embedded C++/MFC.
Inside my DIME payload I am sending SOAP as ASCII text with a type
descriptor set to 'servername/soap'. I now need to do encryption on some
packets and only for some clients. Rather than pay the performance hit
on every connection, only the ones with a DIME type of
'servername/soap-enc' with be [de/en]crypted.

DIME gave us a low overhead, standard way for clients and servers to
communicate. We can even change payload types rapidly by focusing on the
processing and not the transport packing and unpacking. MIME and dozens
of others give us the same thing, but DIME was easy and worked perfectly
for our needs.

Bottom line is that it was easy to implement, it is fast (relative to
other wire schemes), is lightweight, and is binary. This was a clear
winner in our case.

One caveat is that we did not implement the chunking protocol yet since
our payload sizes are somewhat small.

David

-----Original Message-----
From: Discussion of DIME technology [mailto:[email protected]] On
Behalf Of Henrik Frystyk Nielsen
Sent: Saturday, April 13, 2002 6:17 PM
To: [email protected]
Subject: Re: [DIME] DIME Use Case?


>Even if DIME is simpler to implement than such a profiled
>MIME, it seems that this simplicity is mitigated by two factors:

It all depends on what you need - if you need MIME then MIME is clearly
the way to go. Many applications, however, does not need the flexibility
that MIME provides. At some level, the purpose of DIME is really to
allow you to make a clean choice between which description framework you
which to use: MIME, XML, or something else entirely.

As such, DIME is not a replacement for MIME - it is a way for enabling
you to choose which framework you want to use. If you want MIME then you
can wrap that in DIME, if you want XML then you can wrap that and so on.

Henrik Frystyk Nielsen
mailto:[email protected]