Re: Wanted:MAIL.MAI structure definition

david20@xxxxxxxxxxxxxxxx wrote:

In recent years pure relational databases such as Oracle have changed to allow
the storage and retrieval of opaque data such as images so yes you could store
and retrieve opaque mail message objects but I don't see what advantage that
gives you.

Other than resolving the "the existing mail data store is rather more limited than I would prefer?" matter?

And commercial databases have been capable of arbitrary storage for eons. This includes opaque objects.

In a previous message you also mentioned XML with the comment

"
I would also propose storing the data in a database, and allowing the
external software to access the data via XML; to allow data imports and
exports using XML. This gets the other software out of the business of
processing RFC-compliant headers. (And, going full circle, if SMTP mail
were to be (re)implemented today, it is exceedingly likely that XML
would have been used as the basis of the wrappers.)
"

SMTP mail and all the software out there which processes RFC-compliant headers
is not going to be reimplemented using XML anytime soon.

Hence my "if SMTP mail were to be (re)implemented..." comment.

The existing SMTP RFC scheme is a very old design, albeit a widely accepted and functional design. If most anyone here were to redesign the SMTP mail traffic, the result would likely be using XML. (Wanna spot bad headers? Verify it with a schema. Want to extract data from the header? Grab it. What to add extensions? Have at. Want to implement attachment encoding? Trivial.)

And I'd tend to provide the XML in parallel to the existing RFC-based approaches -- assuming there isn't already an RFC for XML-based mail.

If you store mail messages you must be able to present them with all their RFC
headers, Mime structure, PGP signatures etc intact
This isn't a static environment new headers are being created constantly -
sometimes pretty much standardised such as the new header lines for "anti-forging" techniques such as DomainKeys and SPF - sometimes just locally introduced headers (which should be X-???? header lines but often aren't).

That software evolves is obvious. XML is very good at dealing with this, both from generating the new information and from being able to operate when newer information is presented to an older client.

Who's to say that providing a parallel XML interface won't be accepted? It would certainly make a reasonable RFC, as a start -- again, if there isn't already an XML MAIL RFC around.

Oracle's XML appears to support two types of storage CLOB (which maintains
document fidelity and appears just to be an opaque object) and O-R storage
which maintains document object model fidelity by decomposing the XML into the underlying O-R structures.
I would maintain that to store mail messages you would need to use CLOB
storage.

Databases store data. Data is data. Data is bytes. Bytes can be stored. Metadata can be stored. Data structures can be reconstituted. You can store a music file as a series of linked data records.

Converting SMTP mail to other formats (as for instance Exchange does) is one of the main ways of producing software which has problems interoperating with
other SMTP compliant systems. I think that breaking up mail messages using an
XML schema to store them in O-R structures and then reconstructing them for output to SMTP based tools or for forwarding would be prone to errors.

OpenVMS and Windows Exchange Server and most any other tool converts mail -- from its RFC wire format into the local host on-disk format -- all the time. Every mail message arriving into an OpenVMS system gets its format converted. Converted at least twice, if you're using POP3 or IMAP to access and read off the messages from the OpenVMS MAIL data store -- once on the way in, and once on the way out.

[I have to be being dense here as to not see what the concern is, as none of this would be difficult to code up using j-random version of Oracle Rdb and j-random version of libxml2. Most any database itself has in-built XML capabilities, as well.]





.

Relevant Pages

  • Re: ruby / rexml / xpath bug?
    ... puts of the XML. ... end # end each store ... Longitude: -74.107299 ...
    (comp.lang.ruby)
  • RE: Embedd XML within XML - Possible ??
    ... it is not quite recommended that we store such ... If you do want to store complex XML data into the attribute field. ... Microsoft MSDN Online Support Lead ... ID Field and String Field ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: InsertXml - not getting the same result as opening xml file
    ... I will make a suggestion to MS along the lines you have suggested. ... insert the XML file: ... > a template which contains the headers and footers, ...
    (microsoft.public.office.developer.vba)
  • Re: Why choose SQL Express over Access?
    ... I am thinking of coding a data store that many store locations will use to ... get national sales averages. ... Each location sends in its data in in XML ... Ability to do asynch apps ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Mapping Content Controls to External XML
    ... XML in general ... store or some feature of xpath. ... Dim oCC As ContentControl ... Set oCCs = rngStory.ContentControls ...
    (microsoft.public.word.vba.general)