Re: Removal (Time for XMail?)

>Igor Bazdyrev Writes:

> I agree with "... None of this need be visible to the user." part 100%.
And
> I think that the beauty of SOAP and any other XML Protocol providing an
> encapsulation and context abstraction of the payload, is not a possibility
> to standardaze specific application area (such as mailing list). But
rather
> provide mechanism which do not restrict possible Xtensibility of the
> applications (old and new) operating within payload context.

Yeah, that's a definite benefit I see as well. While we're at it, this
brings us back to the whole issue of MIME, and the complexities that MIME
introduces. I can see with a SOAP message the ability to not only carry
relevant MIME data (as a CDATA section, for instance) but also to provide
meta-tag information in the form of RDF blocks that could be easily queried
from an XML parser. For instance, you basically could have:
<resource>
    <header>
        <author>Kurt Cagle</author>
        <resource.name>Cool Graphics</resource.name>
        <keywords>XML Cool Ice Graphic Frozen</keywords>
        <source>http://www.myserver.com/images/mydoc</source>
        <resolution>96</resolution>
        <width>145</width>
        <height>221</height>
        <color.depth>32</color.depth>
        <mime.type>image/jpeg</mime.type>
        <!-- and so forth>
    </header>
    <body><![CDATA[5Aeg30Kla;smFFL;..erL .... ]]></body>
 </resource>

Thus, not only could you store relevant programmatic information such as
resolution, width or color depth, but you also provide a mechanism for
describing the content more effectively, in a form that is consistent both
within mime-types and in general.

> As a practical matter I think that there is nothing wrong with assumption
> that subscribe/unsubscribe directed to the same e-mail address as list.
This
> is because mailing list is a social communication channel. And this
> "virtually" single channel have two different service points:
> one for social communication ("transmit/receive"), and
> another for expressing person's relationships with social group
> ("subscribe/unsubscribe").

> Automatic interfaces and protocols intend to be highly formal and
sensitive
> to "exceptions". Human interfaces, instead, suppose to be "non-validating"
> but automatically handle a human behavioral "exception". So I would rather
> envision SOAP implementation for the server-side input mail filter which
> handles behavioral "exceptions" mentioned above. It need to be distributed
> because filtering can compromize mail server performance.

Again thinking about SOAP implementations -- if you had a SOAP aware XMLSMTP
server then you also have a fault-handling grammar  (though obvious the
implementation of that grammar will determine the characteristics of the
fault-handling). Of course, with a bit of intelligence on the part of the
UI, you'll never need to send out the remove message directly, so that
particular error will seldom crop up.

Another aspect of an XML SOAP message handler is that you can transform the
content dynamically, meaning that it becomes far easier to write generalized
XSLT oriented "servers" that can configure the output to appropriate
devices. Thus, your web browser or cell phone or PDA (or toaster or car
stereo system, for that matter) could effectively display these messages
simply be having the appropriate transforms in place.  It would also fit
well with a paged XForms approach, where a process is described as a series
of state nodes within an XML structure.

-- Kurt Cagle



> Thanks,
> -- Igor Bazdyrev

Received on Friday, 29 September 2000 02:48:19 UTC