webmail

[Conal Tuohy <co...@paradise.net.nz>]

Hi Justin

Just a note to keep you up to date on where I'm at, and maybe provoke some
response:

I've been reading more and more, and thinking and drawing architectural
diagrams ... it's more complicated than I first thought. I think this is an
issue for your project too.

Currently I'm still thinking that the JavaMail access should be a Source,
not implementing XMLizable, i.e. it would provide messages in the
"message/rfc822" format. So that hasn't changed.

The parsing to XML should probably be done by either an XMLizer, or a
Generator. Or possibly, another Source, layered on top of the MIME source.
This is the issue that's exercising me at the moment. The fact is that a
MIME message is not a simple data type: it is in fact a kind of file-system,
with other files and directories in it (the MIME-parts).

The big thing which I'd been neglecting was how to provide access to these
MIME-parts (i.e. a PART of a message) to the relevant components of Cocoon.
For instance, a MIME message may contain a part which is in "text/html"
format, and this html may refer (with an IMG tag) to an image which is in
another part of the MIME message, with an "image/gif" mime-type for
instance. To render this doc to a web-browser as html, or as PDF or
whatever, it will be necessary for the Cocoon pipeline to extract this gif
image from within the message, and feed it to the browser or Batik, as
required. Concretely, the web app will have to generate a web page
containing an IMG with href = some url which Cocoon can then use to find the
gif image from inside that particular message.

Much the same applies to MIME-parts which contain message attachments of
some arbitrary mime-type ("application/octet-stream" is a good one) which
Cocoon can't do anything useful with, but which a browser might understand,
or at least download as files.

I have to do this because my list archive needs to handle attachments.

It seems to me I've got 2 main options:

1) XMLize everything

Currently I'm tending towards using an XMLizer which will convert a
"message/rfc822" byte-stream into SAX events (possibly using the XMSG schema
rather than the XMTP schema I've used before: http://www.w3.org/TR/xmsg/ -
I'm not sure about this yet)

This XMLizer would handle all the MIME-parts (even non-xml parts would be
returned as "lumps" of data) and these could therefore be handled using the
various XML-processing mechanisms: Xinclude, XSLT, etc, etc, even without
necessarily being able to process their actual contents. So a GIF image
MIME-part would appear as a <data> element in the SAX stream:
http://www.w3.org/TR/xmsg/#N632 containing some text-encoded GIF data (i.e.
Base64 encoded). For a binary mime-part, Cocoon processing would be limited
to kind of "routing" it through to the browser, without transforming it on
the way. To use this technique, we'd also need a MIMEPartSerializer which
would decode this part into a binary stream, for return to a browser.

Of course, MIME-parts of XML would be parsed fully, and mime-parts of HTML
would be converted to XHTML with JTidy.

Using this approach, to refer to a MIME-part in the sitemap, you would
generate the full message, then extract the part using a transformer for
instance. There'd be no need to encode everything into the source url used
in the sitemap, and this keeps the Source simple (means we can use a
FileSource to read emails from individual files, too).

2) Handle non-XML parts in their native format

I'm not so clear on how this one would work, but I haven't yet ruled it out
entirely ... I still need to get it clear in my head.

We'd need some component that would return a MIME-part from within a
message, in a native format. It seems to me that it will need to implement
Source (as far as Cocoon is concerned, this is the interface for reading a
non-XML resource). But it must be able to get the MIME-part from either a
file or url or from some kind of JavaMail source. So it would be a Source
layered on top of some other source (AFAIK this would be a unique pattern in
Cocoon, but not unreasonable given the nature of MIME-messages).

I'm not sure if this is really a runner: the MIME-parts contain more data
than a Source could provide. For instance, a Content-Disposition. This is
one reason why I'm inclining towards the XMLizer approach. The trouble is
that Cocoon is set up for doing magic with XML, but non-XML data is either
converted to XML or else just passed through with a Reader. There's no
facility for "pipelines" of non-XML data.


----------------------------------------------------------------------------
----
Whew! I've got another busy day today for another client and may not get
anything done on it, but over the weekend I'll spend some more time on it
and hopefully begin some actual programming work.

I've also been trying to define a URL scheme for referring to JavaMail
resources. This also relates to the "cid:" and "mid:" schemes which are used
for hyperlinks within a given MIME message, though as I said, I'd prefer to
leave this out of the javamail or pop or whatever URLs and deal with it
inside the Cocoon pipeline.

It also relates to how to represent the contents of a JavaMail FOLDER to
Cocoon: whether directly as XML or with mime-type "Multipart/report"
http://www.ohse.de/uwe/rfc/rfc1892.html or "Multipart/digest"
http://deesse.univ-lemans.fr:8003/Connected/RFC/1521/19.html which can then
be XMLized with a Cocoon XMLizer. See
http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html for details of
multipart formats.

Anyway ... I'm off now to have some lunch and then I have to visit a client.
I hope your work is going ok.

Con

RE: webmail

[Conal Tuohy <co...@paradise.net.nz>]

Aaargh ... not enough coffee this morning. My previous message was supposed
to go to Justin directly. My humble apologies for posting off-topic
(would've been OK on the Cocoon-dev list) and in HTML.

Con


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>