james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Mailet API v2
Date Mon, 03 Jun 2002 12:58:20 GMT

I think what you're talking about could be accomplished with a mailet or 
two.  Wouldn't invoking some other application within the middle of 
James' processing do what you need it to do?

So think about this...

<mailet match="Any" class="HandleViaSOAP">

This could make a SOAP call passing the mail and the recipients and 
whatever else.  Return as appropriate.  Alternatively you could write an 
apj mailet...

<mailet match="Any" class="HandleViaAPJ">

Either way, you could have you external app do 1 thing or a hundred 
things, so long as they ultimately tell you how they modified the 
MimeMessage and any adjustments made to the recipient list.
Serge Knystautas
Loki Technologies - Unstoppable Websites

Danny Angus wrote:
> Ok anything then, I stuck on ajp because my use cases are wholly concerned
> with integrating tomcat webapps with james and vv.
> The point is that i think there needs to be *some* protocol that will allow
> james to be used in an integrated way with other applications using
> configuration only, so that it can become a mail gateway without the need to
> write special mailets for each special case.
> I dont suggest that this be in the mailet API, although I did mention it in
> the same mail (because I believe that its part of the same endgame of making
> james more attractive to architects/developers), just that james embraces
> the concept of running as a tool for other applications.
> And a server daemon which processes richer requests than SMTP or POP seems
> to me to be a requirement.
> d.
>>-----Original Message-----
>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>>Sent: 03 June 2002 12:19
>>To: James Developers List
>>Subject: Re: Mailet API v2
>>>>>I also wondered if we should support ajp13
>>>>Do we really need Yet Another Transport Protocol?
>>>The idea of using ajp for this is that it exists already and
>>allows non-java
>>>applications to make or respond to these requests, and recieve the
>>>It allows the mail server and the content server to be remote from one
>>>another, and avoids the limitations of the mail protocols, which dont
>>>provide very sophisticated requests and responses.
>>I'm against ajp for JAMES (for what it is worth).
>>Purist reason :  Do not tie an API to a particular transport
>>Explanation : We're rolling out JMS blocks for general phoenix app use.
>> We're already rolled out a block that uses Graham Glass's truly
>>excellent Glue product to publish arbiatary interfaces to remote SOAP
>>enabled langauges and systems.  We're rolled out the transport package
>>in Cornerstone to similarly publish arbitary interfaces using AltRMI
>>(you guys have still not checked this out).  When the Axis team have a
>>product that is as simple to use as Glue, we'll have a block for that.
>> If Netscape make available a Java API for the truly-visionary XPCOM.
>>we'll write a block for that.  Same story for .Net (assuming we can
>>masquerade as the proprietary TCP based transport).
>>If we could make a general ajp13 adapter for arbitarty interfaces, then
>>perhaps it would be a good thing.  Asa general transport rather than a
>>tightly-coupled solution for Maillets, that is.
>>- Paul

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message