James/Cocoon integration

["Noel J. Bergman" <no...@devtech.com>]

> > > is there a way to transform XML marked-up email to a standardized
email
> > > format?

> > The nice way to do that would be to include a Cocoon pipeline into
James.
> > I'd love to see that happen.

> Do you want a cocoon pipeline for an example integration?

Absolutely.  :-)

> I just asked on cocoon-dev if anything exists and received one response
> from a committer, so far, saying they haven't heard of anything.

The topic came up in the past
(http://archives.apache.org/eyebrowse/ReadMsg?listName=james-user@jakarta.ap
ache.org&msgId=591219), but I don't believe that anyone has worked on it.

> Do you have any basic instructions on how this could be integrated?
> Is it a mailet? Processor?

Others may feel differently, but my thought is that it would be best to make
it a processor within James, and not a mailet.  A mailet is portable, but
Cocoon is already an Avalon technology consumer, has fairly robust interest
in XML configuration, has its own notion of a pipeline, etc.  An
introduction to internals might help to explain my reaosning.

Both processor and mailet have similar entry points:

    public void Processor.service(MailImpl mail) throws MessagingException;
    public void Mailet.service(Mail mail) throws MessagingException;

MailImpl is a James-specific subclass of the generic Mail class.  Mail
represents the SMTP envelope and other server-related attributes, and has a
reference to the JavaMail Message.  Processor.service() is called by
JamesSpoolManager.process(), and calls the matcher and mailet entry points
accordingly, e.g., LinearProcessor maintains a linear list of matcher/mailet
pairs, and calls match/service.

The responsibilities are:

   JamesSpoolManager: retrieve from spool, call service, remove GHOST from
spool.
   Processor: Move message through a process.  Handle exceptions
              that happen during matcher/mailet processing.  If
              message "state" changes, re-spool message for the
              new state.
   Mailet: process a message.  Can set message state (new queue)
           and/or send new message(s).

The spool manager is the queue interface.  It is a pull consumer.  Processor
and Mailet are synchronous push consumers.  Processors are 1:1 with virtual,
named, queues.  Mailets are embedded within processors, and gated by
matchers.

Cocoon has its own pipeline, with its own filtering and processing notions.
I don't believe that it makes sense to embed Cocoon inside of a Mailet.
Instead, I believe that what we do is implement the class attribute for the
processor element, and have a Cocoon processor, e.g.,

  <processor name="prepareMailing"
class="org.apache.James.transport.CocoonProcessor">
    ...
  </processor>

A Cocoon processor would have full access to Avalon services, classloaders,
etc.  Mailets will be more restricted in what they can do, and what classes
they can access.

A Road Map would be to refactor LinearProcessor into an interface, generic
base class, and specialized LinearProcessor implementation; and add support
for the class attribute.  We would need someone fluent in Cocoon to work the
Cocoon pieces and sample application(s).

It also seems to me that we'd need an XML mapping for an RFC 2822/2045
message, e.g., XMTP (http://www.openhealth.org/xmtp/XMTP1.0.html), for which
there is a Java implementation (http://www.openhealth.org/xmtp/).  As I
understand Cocoon, we'd need an XMTPGenerator (MIME -> SAX Events) and
XMTPSerializer (SAX Events -> MIME).

	--- Noel

Re: James/Cocoon integration

[Vadim Gritsenko <va...@verizon.net>]

Noel J. Bergman wrote:
...

>As I
>understand Cocoon, we'd need an XMTPGenerator (MIME -> SAX Events)
>

Yes, that would be needed, but that won't be the most used component for 
"mailapps" (drawing a parallel with webapps, XMTPGenerator to mail is 
what StreamGenerator to HTTP -- it's not used that very often), and 
won't be necessary generator.

What used more often are headers of the email. Imagine ezmlm in 
James/Cocoon: what you need from the incoming email is usually the 
subject ("URL" :). And you want to get this subject in your sitemap to 
match against it. So first you need is to write Cocoon environment to 
populate request parameters and request URL and such from the Java mail 
object.

You will need XMTPGenerator too to get an email body - it's just not the 
first part which comes to mind. Or, even better, you should compare 
email to handling mime-multipart HTTP request. Then, you can use 
existing RequestGenerator and StreamGenerator instead of writing 
XMTPGenerator (which is still possible to write - but much less reasons to).


> and
>XMTPSerializer (SAX Events -> MIME).
>

TextSerializer for plain text emails, HTMLSerializer for html, Mime 
multipart serializer - for mail with attachements. Environment should 
convert Cocoon Response object into Java Mail object.

Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: James/Cocoon integration

[Vadim Gritsenko <va...@verizon.net>]

Noel J. Bergman wrote:
...

>As I
>understand Cocoon, we'd need an XMTPGenerator (MIME -> SAX Events)
>

Yes, that would be needed, but that won't be the most used component for 
"mailapps" (drawing a parallel with webapps, XMTPGenerator to mail is 
what StreamGenerator to HTTP -- it's not used that very often), and 
won't be necessary generator.

What used more often are headers of the email. Imagine ezmlm in 
James/Cocoon: what you need from the incoming email is usually the 
subject ("URL" :). And you want to get this subject in your sitemap to 
match against it. So first you need is to write Cocoon environment to 
populate request parameters and request URL and such from the Java mail 
object.

You will need XMTPGenerator too to get an email body - it's just not the 
first part which comes to mind. Or, even better, you should compare 
email to handling mime-multipart HTTP request. Then, you can use 
existing RequestGenerator and StreamGenerator instead of writing 
XMTPGenerator (which is still possible to write - but much less reasons to).


> and
>XMTPSerializer (SAX Events -> MIME).
>

TextSerializer for plain text emails, HTMLSerializer for html, Mime 
multipart serializer - for mail with attachements. Environment should 
convert Cocoon Response object into Java Mail object.

Vadim