More specifically, what happens when the XML-dispatching program decides,
"Surprise! The original client is the agent best suited to display of this
particular XML object." The problem is that even in tightly integrated plug
in
setups there's usually no way to communicate this sort of thing back to the
client's dispacher to the point where a truly seamless display can be
achieved.
The inevitable result is suboptimal integration, which users, myself
included,
loathe.
I can't agree with you here. Yes, Eudora does this badly, but I think this
is a problem with the implementation, not the idea. If an MUA or Web
display engine says "I can natively display a stream of XML", then the
integration with an intermediary is not difficult at all.
Actually, in my opinion Eudora is far and away the best agent out there when it
comes to this sort of thing, which is why I held it up as a fairly unique
counterexample to what I see as the current state of affairs. Nothing else I've
seen even comes close to having Eudora's capabilities.
If you know of something else I'd like to hear about it.
This is another instance of a problem we first encountered with security
multiparts: When you dispatch handling of a security multipart to a separate
application, getting the enclosed data back to the original client often
isn't possible. And while a few clients have adopted plugin architectures
that address this (Eudora, for example), most have not, and worse, plugins
capable of working really well in such environments have been slow in
coming.
I've spoken with people who make such plugins (such as the ones I try to
use with Eudora), and they complain about the Eudora API, not about their
ability to hand back blobs of text to the program. In my mind, this can't
be all that hard for data types that the original program knows how to
handle, particularly if they are guaranteed not to get back a multipart.
Well, as it happens I'm familiar with the Eudora API -- I was asked to review
its capabilities in this area some time back, and I liked them so much that I
modelled some aspects of a similar API in our product after what Qualcomm had
done.
So while I cannot claim to have actually written code to the Eudora API, I can
claim to have developed a similar API and written code that uses it to do
similar things. And I can assure you that not only are such transformations
possible, they are easy to implement using APIs of this sort.
So I'm afraid I'm not prepared to accept the complaints you have heard as
valid. Perhaps they were directed at an earlier version of Eudora, or something
like that.
(Please note that I don't work for Qualcomm and I only use Eudora rarely. So I
have no vested interest in their MUA.)
To me, the problems of "original clients" displaying XML handed back to
them from a process that decides what goes where isn't a serious issue. The
more serious issue in my mind is that we are starting to get a significant
number of XML formats and some viewers, and we haven't agreed to a method
for them to link those through MIME. I think we need to say "yes, MIME is
your linkage and here's exactly how" (which I don't think we are ready to
do), or we must say "MIME is not your linkage and you need to come up with
your own methods."
Again, I don't think you can say either one is right in general. I think that
for some applications separate MIME types are appropriate and necessary; for
others a single MIME type for an entire family of things is appropriate; and
for others a generic MIME label is fine.
Ned