You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/06/03 07:43:00 UTC
Mailet API v2
> rename matchers as "interceptors"
Matchers seem to me to be well-named, except that they can have effect, not
just match. The mailet tag
<mailet match="matcher" class="mailet" />
to me is similar to an IF statement. It produces its primary effect by
returning a filtered recipient list, although it can have side-effects.
> use mail headers ...
How does this differ from what is already provided by the
MimeMessage.setHeader() method?
> I also wondered if we should support ajp13
Do we really need Yet Another Transport Protocol?
As for the Servlet API, where do you see the mapping? Some are obvious
(contexts and configs), but others are less so. For example, I could argue
the mailets are more like filters than servlets, and there are some things
that just don't seem to map well between a Mailet container and a Servlet
container.
Servlets are based upon a request/response model. In the case of James, the
request-response is implemented in the protocol handlers. Oddly enough,
SMTPHandler.parseCommand() seems the closest thing to a servlet's service()
method. Internally, Collection Matcher.match(Mail) and void
Mailet.service(Mail mail):
a) don't generate responses
b) are chained by the container
I'd be more likely to view Mailets perhaps as filters (with a null
response?) than servlets. A Matcher causes conditional execution and muxing
(effectively generating internal requests). It could be simulated by having
the Matcher use a RequestDispatcher, but I'm not sure how best to map the
functionality, off-hand. Processors, I suppose, could be viewed as some
form of filter chain.
I'm not convinced that it is necessary to change the Mailet API to a
subclass of Servlet API in order to decouple the mailet, matcher, processor
package from the James server code.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Paul wrote, (in re. Mailets..)
"Interestingly, this overlaps with some pattern/design issues. I'll
discuss them, but perhaps it is all pointless as you have a published
API and you are supporting a user community. [snip] perhaps for Maillet2
API."
Its funny that you should mention this.. as you know I'm looking at
developing a mailet sdk version of James, basically a mailet developer
friendly distribution.
I've also got the idea in the back of my head that mailets should be
servlets, not http servlets (obviously) but as the servlet API is designed
to support any protocol I thought mailets could, and probably should, be
built on the servlet API, and extended to include "newslet" functionality to
allow identical handling of mail and news messages.
In addition I'd thought that we should do four other things which point
towards a version 2 of the mailet API,
a) rename matchers as "interceptors" because it is a better description of
their role
b) build a standalone mailet container that developers can easily include in
their own products (but I'm a complete no-hoper when it comes to
classloaders) such that app developers could use it to process mail
generated by their apps before it is sent, or mail delvered to their app by
any means, particularly other than by built-in SMTP reception. This should
support at least, dynamic re-configuration of processors (classloading)
and mailets, and when complete could be used to replace the existing SMTP
mailet context and add a mailet context to NNTP.
c) use mail headers, or some other method which doesn't depend upon anything
other than the mailet API, to allow the attachment of serialisable
attributes to mails, after all thats what X- headers are for.
d) create a wholly encapsulated method of deploying mailet applications
(a-la .war files), such that it would include its own mailet processor
configuration(s) and the only config needed in James would be to specify an
entry-point, using "to processor"
(slightly OT I also wondered if we should support ajp13 to allow other
applications to insert mail into the spool, and to allow mail to request
stuff from other ajp apps. but I've not looked at the ajp spec to see if its
suitable for this role)
I don't expect I'll have time to do much of this, or any of it very fast,
but I do believe we should ..
1/ think about separating the mailet API from the James code
2/ discuss the shape of mailet API version 2
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm thinking more along the lines of a junit testing framework.
How do we test with all of the things with whicht a matcher or mailet might
interact? I might need to be testing my use of the config and context,
testing my processing based upon the mail content or some information (e.g.,
quota) from the user repository, etc. How much of the container's
environment do you want to simulate, compared to running test messages
through a test configuration?
The real PITA is the lack of dynamic loading for the packages, so one has to
rebuild and relaunch.
> 2) a whole bunch of emails in one directory
Technically, there is nothing to prevent a mailet from doing that, is there?
:-)
<mailet match="RecipientIs=testing@localhost" class="TestGenerator">
<directory>/usr/local/james/testmessages/</directory>
</mailet>
The TestGenerator mailet would create and mail each message found in the
designated directory.
> 3) outputs of each email from (2) after the mailet or matcher in (1) ran.
At the moment, I should find this in the logs.
I'm not saying that a standalone container would not be useful, but I am
saying that more than a bit of environment is exposed to matchers and
mailets, so the container is not going to be all that much smaller than
James (ok, it won't need the handlers or remote user admin).
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>Again, I think a "testing kit" might be a better approach.
>
>
> In the meantime, why not have something like:
>
> ...
> <mailet match="RecipientIs=testuser@testhost" class="ToProcessor">
> <processor>testing</processor>
> </mailet>
>
> <processor name="testing">
> <mailet ...>
> </processor>
>
> By adjusting the initial matcher, I can control whatever I want to send to
> my testing processor, where I can test my matchers and mailets. I can do
> this on a standalone system, or specify a special port for a test version of
> james.
I'm thinking more along the lines of a junit testing framework. What I
want is basically:
1) a mailet or matcher to test
2) a whole bunch of emails in one directory
3) outputs of each email from (2) after the mailet or matcher in (1) ran.
Then the kit is something that can quickly take 1 and 2 and produce 3.
If you stick this within James, it's harder to capture the output and
run a predetermined set of messages through it. Maybe though...
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
> In the meantime, why not have something like:
because at the end of the day it depends upon James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Again, I think a "testing kit" might be a better approach.
In the meantime, why not have something like:
...
<mailet match="RecipientIs=testuser@testhost" class="ToProcessor">
<processor>testing</processor>
</mailet>
<processor name="testing">
<mailet ...>
</processor>
By adjusting the initial matcher, I can control whatever I want to send to
my testing processor, where I can test my matchers and mailets. I can do
this on a standalone system, or specify a special port for a test version of
james.
Now if only JMeter had SMTP support ...
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> I dont see why the LinerProcessor call to mailet.service(Mail mail)
> shouldn't be regarded as a request/response, with either a null response, or
> a Mail response which would be the original mail modified by the processing,
> and ready for the next step in the processor.
> Nor why the SpoolManager in its role as the manager of the
LinearProcessors
> shouldn't like wise see the call to LinearProcessor.service(MailImpl
mail)
> as an identical request/response
>
The reason we don't is that
a) you could return as the response a message different than what was
passed (makes it harder to handle)
b) we viewed it as a bad design to stick a new message in the middle of
the processing chain.
c) many mailets would not "consume" the message, meaning they'd have to
add extra code to set the response the same as the request.
What we might want to do instead of build another GenericMailet that
consumes messages... then if someone wants to build a consuming mailet,
they can just extend a different class, and they don't have to
understand Mail.GHOST and other such stuff.
> To that end it would be nice to have the Mailet SDK contain a complete
> simple implementation which could be used by developers working on the
> mailet API, mailet developers, and by users who aspire to add a simple
> mailet context to their products.
Again, I think a "testing kit" might be a better approach. Provide
several dozen standard messages, let the user add whatever other ones
they want to form a test suite for their mailet or matcher, then use the
testing kit to run it and let them check the output.
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>Ok anything then, I stuck on ajp because my use cases are wholly concerned
>with integrating tomcat webapps with james and vv.
>
A quick clarification question if I may, bespoke sevlet in WAR needs to
interoperate with James maillets/core ? Or arbiatry maillets (or mail
posting facade) need to be re-published as a home grown XML web-services
API ? ( I need context to understand ).
>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 Agree.
Humour me for a second - Is the API in MailServer.java a good one, if it
were available for external use? Yes I think it is. It provides a
conceptual entry point for internally generated mails yet-to-be subject
to mailet processing.
Second question - Is a hypotehical maillet API (the one now or a proposd
V2 one) a good thing for external use? Yes, I guess it is again.
The point is that you could publish those over a number of transport
schemes to remote applications. These could be Java or non-Java
depending on the publication blocks/tools available today.
>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.
>
As per promise of Phoenix, of via various tranports the promise for
outside-th-phoenix-vm apps.
>And a server daemon which processes richer requests than SMTP or POP seems
>to me to be a requirement.
>
>
Agree. Conjour up your purest API ( and leave publication to other
blocks ) .... is my recommendation.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>>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.
>>
>>
>
>Absolutely, thats exactly what I had in mind, an AJP mailet.
>.. But also a receptor that would create a MIME message and insert it into
>the spool, although it would probably make more sense to expose a spool
>entry point via RMI and provide a utility method that would create simple
>pre-defined MIME messages from strings, like
>
>
There is no need to use anything as cumersome as RMI. We (in
Avalon-Excalibur) have developer AltRMI which allow publishing via
normal interfaces (no extends remote, no throws RemoteException, no
extends UnicastRemoteObject). There is also as SOAP publisher (that
uses Glue) if you want to interoperate with other languages...
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
> Hi - hope you guys don't mind my chiming in.
Not at all..
> It's true that you can configure JAMES to route fetched mail directly to
> the local processor without providing a new entry point, but the
> configuration is easy to screw up. A typo means you risk losing mail,
> wasting other systems' resources, etc.
Thank you, thats another use-case for a mailet container, re-sorting fetched
mail for local distribution.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Ajit George <ga...@kurianinc.com>.
Hi - hope you guys don't mind my chiming in.
Noel J. Bergman wrote:
>And I think it would be more reliable to relay the message from one server
>to another for special processing, than to try to do RMI in the middle of
>the processing chain. Any problems, e.g., sudden server death, are handled
>by the existing spooling and protocols.
>
>What it comes down to is that somewhere along the line, some aspect of
>content and behavior is going to be distributed. You are thinking AJP, Paul
>is talking about AltRMI and SOAP. I'm hanging my case on the RFC and
>existing mechanisms. I don't like inventing new protocols when none seem to
>be needed.
>
One complaint that crops up quite often on the qmail mailing list is
that (some) mail fetching programs relay messages from one server to
another via SMTP. When the receiving server is misconfigured, it relays
the fetched mail instead of storing it (or whatever it's supposed to do)
and you get a loop. So fetched mail should be routed directly to the
local processor.
It's true that you can configure JAMES to route fetched mail directly to
the local processor without providing a new entry point, but the
configuration is easy to screw up. A typo means you risk losing mail,
wasting other systems' resources, etc.
Ajit
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Absolutely, thats exactly what I had in mind, an AJP mailet.
You want a remote matcher/mailet interface? You want to be able to
conceptually run a mailet and matcher in an RMI (concept) server somewhere?
Might I suggest that I view that as a bad idea, in terms of availability and
reliability?
If you want "to expose a spool entry point via RMI and provide a utility
method that would create simple pre-defined MIME messages from strings" ...
well:
- I can do that with a simple MailBean that either speaks SMTP or wraps
javax.mail.
- I can use a matcher in the receiving mailet container (James) to put a
message directly into a particular processor.
And I think it would be more reliable to relay the message from one server
to another for special processing, than to try to do RMI in the middle of
the processing chain. Any problems, e.g., sudden server death, are handled
by the existing spooling and protocols.
What it comes down to is that somewhere along the line, some aspect of
content and behavior is going to be distributed. You are thinking AJP, Paul
is talking about AltRMI and SOAP. I'm hanging my case on the RFC and
existing mechanisms. I don't like inventing new protocols when none seem to
be needed.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
> 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.
Absolutely, thats exactly what I had in mind, an AJP mailet.
.. But also a receptor that would create a MIME message and insert it into
the spool, although it would probably make more sense to expose a spool
entry point via RMI and provide a utility method that would create simple
pre-defined MIME messages from strings, like
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Serge Knystautas <se...@lokitech.com>.
Danny,
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">
<url>http://blah/mailprocessor</url>
</mailet>
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">
<foo>bar</foo>
</mailet>
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
http://www.lokitech.com
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
>>
>>
>>Danny,
>>
>>
>>>>>I also wondered if we should support ajp13
>>>>>
>>>>>
>>>>
>>>>Do we really need Yet Another Transport Protocol?
>>>>
>>>>
>>>
>>><snip/>
>>>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
>>>responses.
>>>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.
>>
>>Regards,
>>
>>- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>Wait a minute ... are we talking about the same thing? I agree that there
>needs be a Mailet API that is a real, first class, Java API for
>Matchers/Mailets to interact with the container environment.
>
+1
>I am
>disagreeing with the proposals that use AJP or other protocol to effectively
>run matchers/mailets in RMI servers separate from the container. I am
>disagreeing with an archtecture organized around distributing the server
>across its internal architecture, as opposed to distributing process at the
>message level, using the RFC-defined protocols.
>
Well I am not against remote capaility. I'm not a JAMES user, I'm just
Avaloner interloper looking for a block-centric Java world. I'm here to
advocate solutions from the Avalon family.
>I thought that you were advocating the use of AltRMI or SOAP. I didn't
>realize that you were raising those spectres purely to suggest that the
>issue of distribution be ignored, and the actual API be the focus.
>
I am for the use of such tools to publish _arbitary_ Java interfaces if
you need to publish them.
http://www.themindelectric.com/glue/index.html
http://jakarta.apache.org/avalon/excalibur/altrmi/
I am avocating them *over* RMI or AJP11/12/13 or similar which are tied
to a particular transport. and cost the API developer much angst.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
Paul,
Wait a minute ... are we talking about the same thing? I agree that there
needs be a Mailet API that is a real, first class, Java API for
Matchers/Mailets to interact with the container environment. I am
disagreeing with the proposals that use AJP or other protocol to effectively
run matchers/mailets in RMI servers separate from the container. I am
disagreeing with an archtecture organized around distributing the server
across its internal architecture, as opposed to distributing process at the
message level, using the RFC-defined protocols.
I thought that you were advocating the use of AltRMI or SOAP. I didn't
realize that you were raising those spectres purely to suggest that the
issue of distribution be ignored, and the actual API be the focus.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>>You missing a central point of what I propose - have a first class API
>>
>>
>
>Define a message delivery API, do it in SOAP, make it language neutral, and
>submit it as an RFC. THEN you'll have something. A SOAP interface to
>replace SMTP and other message delivery protocols makes sense, but the model
>should not be tightly tied to any language or implementation. My objection
>is to an ad hoc protocol entwined with a particular architecture, rather
>than abstract concepts of message delivery.
>
SOAP is not first class. I am not proposing it. I am proposing a Java API.
>>constructing something around SMTP, then forgetting easier
>>(from the programmers point of view) ways of poking it.
>>
>>
>
>I've never thought of SMTP as a difficult protocol. But then again, I've
>been known to send e-mail via telnet. SMTP can have a perfectly simple
>object interface: set content, set recipients, send the message. It is not
>an interactive interface, but that's not its purpose.
>
>
It is more difficult than Java. If it is great why do we not have a
Hashmap interoperated with via SMTP (for example).
>>What we are talking about here is direct to JAMES/maillets API, yes?
>>
>>
>
>That became clear later, and I maintain that THAT is a bad idea. Having to
>take into account that any given matcher or mailet could be remote (and
>perforce unreliable) is going to really complicate spool processing, and I
>honestly see no point to it when I can send the message via SMTP or LMTP
>from one mail server to another, just as we do with almost every other mail
>server on the planet.
>
All of them, any of them, some of them.... Some front end API that
firewalled them all. It is not such a bad idea.
>>For you information, there are loads of people using AltRMI and SOAP for
>>
>>
>RPC.
>
>I am well aware of SOAP and other RMI mechanisms (I'm one of those sick
>people who browses http://www.xmethods.net to see what's new). As I said,
>I'm in favor of a SOAP interface that is based upon the problem domain, not
>the solution domain.
>
I am not propsing a SOAP or AltRMI or SMTP API. I am proposing a Java
one. Then and only then thing of secondary adapters that present it to
the outside world. Add in additional concepts like TLS, AAA and you're
got multiple faces to the same JAMES concept - a specially designed API.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
> Define a message delivery API, do it in SOAP, make it language
> neutral, and
> submit it as an RFC. THEN you'll have something. A SOAP interface to
> replace SMTP and other message delivery protocols makes sense,
> but the model
> should not be tightly tied to any language or implementation. My
> objection
> is to an ad hoc protocol entwined with a particular architecture, rather
> than abstract concepts of message delivery.
I don't believe that anyone is considering trying to invent new message
delivery anything.
> That became clear later, and I maintain that THAT is a bad idea.
> Having to
> take into account that any given matcher or mailet could be remote (and
> perforce unreliable) is going to really complicate spool processing, and I
> honestly see no point to it when I can send the message via SMTP or LMTP
> from one mail server to another, just as we do with almost every
> other mail
> server on the planet.
But they all originate somewhere, and I was originally suggesting that James
could originate email as a service for other *Java* applications.
And anyway I think you've made your opposition to this pretty clear now.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
Paul,
> SMTP, whether with helper libs or not, is not a first class Java API.
> You missing a central point of what I propose - have a first class API
Define a message delivery API, do it in SOAP, make it language neutral, and
submit it as an RFC. THEN you'll have something. A SOAP interface to
replace SMTP and other message delivery protocols makes sense, but the model
should not be tightly tied to any language or implementation. My objection
is to an ad hoc protocol entwined with a particular architecture, rather
than abstract concepts of message delivery.
> constructing something around SMTP, then forgetting easier
> (from the programmers point of view) ways of poking it.
I've never thought of SMTP as a difficult protocol. But then again, I've
been known to send e-mail via telnet. SMTP can have a perfectly simple
object interface: set content, set recipients, send the message. It is not
an interactive interface, but that's not its purpose.
> What we are talking about here is direct to JAMES/maillets API, yes?
That became clear later, and I maintain that THAT is a bad idea. Having to
take into account that any given matcher or mailet could be remote (and
perforce unreliable) is going to really complicate spool processing, and I
honestly see no point to it when I can send the message via SMTP or LMTP
from one mail server to another, just as we do with almost every other mail
server on the planet.
> For you information, there are loads of people using AltRMI and SOAP for
RPC.
I am well aware of SOAP and other RMI mechanisms (I'm one of those sick
people who browses http://www.xmethods.net to see what's new). As I said,
I'm in favor of a SOAP interface that is based upon the problem domain, not
the solution domain.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>>Nothing, but it is hardly a Java friendly API.
>>
>>
>
>How so? Create a mail message, add recipients, subject, content, send to
>server. Easy as pie. Even without javax.mail (a bit over engineered),
>there are ez-mail classes (or wrappers). I've been using the same simple
>MailBean for years with servlets and JSP pages.
>
>
hello("Is this a Java firendly API"); ?
SMTP, whether with helper libs or not, is not a first class Java API.
It is a plain-text using protocol that is ubiquitous and has multiple
implementations.
You missing a central point of what I propose - have a first class API
in Java, and have a number of ways of poking it (including SMTP). What
I think is inferior is constructing something around SMTP, then
forgetting easier (from the programmers point of view) ways of poking it.
>>Besides, stategic use of AltRMI or Glue will allow publishing
>>of arbiary Java interfaces. There are a dozen places in JAMES
>>code where a niche publication could occur... at no cost of
>>developing the remote API.
>>
>>
>
>I am firmly against protocol proliferation when it is unnecessary. If/when
>there is a change from SMTP/IMAP/POP/NNTP to some XML messaging protocol(s),
>there would need to be RFCs with the same kind of scope as the current
>protocols. Not ad hoc SOAP or RMI interfaces.
>
Who said change? JAMES is a mail server, it must speak RFC specified
protocols. Whet we are talking about here is direct to JAMES/maillets
API, yes?
For you information, there are loads of people using AltRMI and SOAP for
RPC. They have not felt the need to get an RFC around their API. You
folks don't have to either. Whether you talk of a new JSR or not (I am
on the committee of JSR 111). You can make a defacto standard you know.
It is not wrong to do so as you are the only mail server of consequence
in the Java world.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Nothing, but it is hardly a Java friendly API.
How so? Create a mail message, add recipients, subject, content, send to
server. Easy as pie. Even without javax.mail (a bit over engineered),
there are ez-mail classes (or wrappers). I've been using the same simple
MailBean for years with servlets and JSP pages.
> Besides, stategic use of AltRMI or Glue will allow publishing
> of arbiary Java interfaces. There are a dozen places in JAMES
> code where a niche publication could occur... at no cost of
> developing the remote API.
I am firmly against protocol proliferation when it is unnecessary. If/when
there is a change from SMTP/IMAP/POP/NNTP to some XML messaging protocol(s),
there would need to be RFCs with the same kind of scope as the current
protocols. Not ad hoc SOAP or RMI interfaces.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>>AltRMI (transport package of Cornerstone), SOAP (Glue) .... :-)))
>>
>>
>
>What is wrong with instantiating an SMTP or IMAP client if I want to send
>mail?
>
>
Nothing, but it is hardly a Java friendly API. Besides, stategic use of
AltRMI or Glue will allow publishing of arbiary Java interfaces. There
are a dozen places in JAMES code where a niche publication could
occur... at no cost of developing the remote API.
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
> >If you want to have extensive mail functionality available to your
> > application, but *not* on the same box(es) use James.
>
> AltRMI (transport package of Cornerstone), SOAP (Glue) .... :-)))
What is wrong with instantiating an SMTP or IMAP client if I want to send
mail?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>If you want to have extensive mail functionality available to your
>application, but *not* on the same box(es) use James.
>
>
AltRMI (transport package of Cornerstone), SOAP (Glue) .... :-)))
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
> You'd be better splitting those maillet visible james classes into
> interfaces in the aillet API and keeping the impl in the james codebase.
> This way the maillet-api.jar is a lean as possible. Interface/impl
> separation is good thing :
> http://jakarta.apache.org/avalon/framework/guide-patterns-soii.html.
> It is possible f course that I've caught the 'wrong end of the stick'
> and this is already the case...
I believe that it is, at least in principle, but I haven't done a lot of
checking.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>As far as mailet API dependancies on james utility classes, that just
>requires a simple re-factoring to deprecate the classes in o.a.james in
>favour of identical classes in o.a.mailet.
>
>I know that there is work involved in this, and I do still believe that it
>is worth embarking on it.
>
You'd be better splitting those maillet visible james classes into
interfaces in the aillet API and keeping the impl in the james codebase.
This way the maillet-api.jar is a lean as possible. Interface/impl
separation is good thing :
http://jakarta.apache.org/avalon/framework/guide-patterns-soii.html.
It is possible f course that I've caught the 'wrong end of the stick'
and this is already the case...
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
> Register with james. When mail arrives (from or to you), the mailets will
> take it from there. There is no need to tightly integrate an application
> into James' code, via some ad hoc protocol or RPC/RMI/SOAP.
Except that they can be much richer, and more appropriate protocols than
SMTP
> James
> is nothing more than a mailet container with protocol handlers,
> content and
> user repositories, matchers and mailets.
Actually James is a lot more than a mailet container, most of James is
concerned with spoolmanagement, repositories and protocols, and making
protocols comply with all the fine detail of all the relevant RFC's is no
walk in the park, even now there are still new compliance issues being
raised.
> Fine? I get the main mailer to forward any or appropriate messages to my
> stripped version of James, running my calendar mailets, and do my
> processing
> there. What problem do you see?
Your stripped version of James is running in a different JVM, it cant share
objects with your business logic without becoming "distributed" if your app
could instantiate a mailet context you reduce the complexity of the problem,
and mailets become an attractive solution to mail processing.
> True. But at the moment there is a good deal of environment exposed to
> Matchers and Mailets. ComponentManager, DataSourceSelector;
> various stores,
> repositories, contexts and configs; etc., not counting Mail and
> MimeMessage.
> I'm sure you realize better than most what it will take to remove
> all import
> org.apache.avalon.* and from matchers and mailets, not to mention
> org.apache.james, so that all that's left is org.apache.mailet.* and
> javax.mail.*. Until and as that API is defined, I don't see any feasible
> decoupling of the Mailet API from Avalon.
I take your point, and agree that any decoupling may have to define a
repository interface and the context may have to provide some new services
for the mailets, but the API doesn't have to provide those services, just
define what is minimally required. it would then be up to implementations to
provde them , using avalon if the implementors want to.
Likewise none of the contents of the James transport mailet/matcher packages
would *have* to use context provided services, they would simply no longer
be compliant and not portable to complient contexts, but if the context
provided them in a compliant way it would be able to contain compliant
mailet applications as well.
Similarly a simple implementation of the mailet API wouldn't need to provide
the sophisticated variety of configuration options that James does.
In fact it would be nice to see the mailet API attract new users to James
because of its more sophisticated implementation.
As far as mailet API dependancies on james utility classes, that just
requires a simple re-factoring to deprecate the classes in o.a.james in
favour of identical classes in o.a.mailet.
I know that there is work involved in this, and I do still believe that it
is worth embarking on it.
d
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Yes, I want to see mailet processing made available to applications that
> might like to use email but don't want the hassle.
> If your app would like to send mail, let James take the strain.
> If your app would benefit from recieving mail, again let James take the
> strain.
Register with james. When mail arrives (from or to you), the mailets will
take it from there. There is no need to tightly integrate an application
into James' code, via some ad hoc protocol or RPC/RMI/SOAP.
> > Seems to me that a "container" has a port, a protocol, and a server
> > (processor) -- I am using these terms at a level of abstraction.
> > I'd find it more intuitive to see mailets associated with the SMTP
server,
> > newslets with an NNTP server, etc.
> I believe that this would unnecessarily constrain the mailet API
Not at all. Mailets are as ignorant of such details as they can be given
the level of abstraction in the API (it remains to be seen how much a
Newslet differs from a Mailet in terms of the semantics of the news vs mail
notions).
> Of course my grand plan is that it would be just as simple to add mailet
> functionality to anything
I understand. I was trying to give the abstract notion of such a container.
But I don't think that you'll want to embed the container in the
application. More likely, you'll embed (part of) the application in the
container.
> You might want to build a huge and dynamic set of local delivery rules for
> mail, with heirarchies and precedence, priorities, configurable and
default
> behaviours, you don't need to use James to do both if you have a dedicated
> mailet container elsewhere, protected from DOS and hacking, which collects
> its mail from James and uses James as its SMTP gateway.
Sounds like a particular configuration of James. How does it differ? James
is nothing more than a mailet container with protocol handlers, content and
user repositories, matchers and mailets.
> Or your application might be an intranet with shared calendars, and a
mailet
> application which would be able read and generate icalendar messages, but
> you're not allowed to run your calendar application in James (your boss
wont
> let you, its not policy), so you run it using the default mailet container
> in whatever platform your boss spent all that money on last year.
Fine? I get the main mailer to forward any or appropriate messages to my
stripped version of James, running my calendar mailets, and do my processing
there. What problem do you see?
> After all a good API need be nothing more than a coherent collection of
> rules enforcing a pattern and offering interoperablility.
True. But at the moment there is a good deal of environment exposed to
Matchers and Mailets. ComponentManager, DataSourceSelector; various stores,
repositories, contexts and configs; etc., not counting Mail and MimeMessage.
I'm sure you realize better than most what it will take to remove all import
org.apache.avalon.* and from matchers and mailets, not to mention
org.apache.james, so that all that's left is org.apache.mailet.* and
javax.mail.*. Until and as that API is defined, I don't see any feasible
decoupling of the Mailet API from Avalon.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
> It seems that you are thinking of using James as something other
> than a mail
> gateway. Can you elaborate on what you're trying to do?
Yes, I want to see mailet processing made available to applications that
might like to use email but don't want the hassle.
If your app would like to send mail, let James take the strain.
If your app would benefit from recieving mail, again let James take the
strain.
If you want to have extensive mail functionality available to your
application, but *not* on the same box(es) use James.
> Seems to me that a "container" has a port, a protocol, and a server
> (processor) -- I am using these terms at a level of abstraction.
> I'd find it more
> intuitive to
> see mailets associated with the SMTP server, newslets with an NNTP server,
> etc.
I believe that this would unnecessarily constrain the mailet API, of itself
it only really requires spooling and repository services to be provided. And
as such it seems to me that the spool manager is the ideal location for it.
Of course my grand plan is that it would be just as simple to add mailet
functionality to anything, NNTP in particular, and indeed to applications
which don't provide conventional mail services.
You might want to build a huge and dynamic set of local delivery rules for
mail, with heirarchies and precedence, priorities, configurable and default
behaviours, you don't need to use James to do both if you have a dedicated
mailet container elsewhere, protected from DOS and hacking, which collects
its mail from James and uses James as its SMTP gateway.
Or your application might be an intranet with shared calendars, and a mailet
application which would be able read and generate icalendar messages, but
you're not allowed to run your calendar application in James (your boss wont
let you, its not policy), so you run it using the default mailet container
in whatever platform your boss spent all that money on last year..
After all a good API need be nothing more than a coherent collection of
rules enforcing a pattern and offering interoperablility. Even though I
advocate distributing a number of implementations of mailet interfaces its
implementation can legitimately be the concern of the user.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
I believe that ajp is inappropriate, given that it is geared for HTTP
interactions. I accept that "there needs to be *some* protocol that will
allow james to be used in an integrated way with other applications [so]
that it can become a mail gateway without the need to write special mailets
for each special case" but I don't see the problem. Applications can use
any mail client classes, and James is interchangable with any mail server
supporting IMAP, SMTP, LMTP, etc.
> a server [that] processes richer requests than SMTP or POP seems
> to me to be a requirement.
It seems that you are thinking of using James as something other than a mail
gateway. Can you elaborate on what you're trying to do? From your comment
about needing to write special mailets, it sounds as if you want the
applications to be able to have special processing performed on the mail.
If so, why NOT a mailet? The issue would seem that if an application needed
some special handling, then we'd want an API to dynamically configure James.
This would tie in with some of your other comments regarding a mailet
container.
Seems to me that a "container" has a port, a protocol, and a server
(processor) -- I am using these terms at a level of abstraction. The
current config file should probably change a bit because it seems to me that
the processors are associated with the SpoolManager, whose connection with
the SMTP "container" does not seem explicit. I'd find it more intuitive to
see mailets associated with the SMTP server, newslets with an NNTP server,
etc. Were this the case, then I could see how a new container could be
instantiated (and what that would mean), or a change made to an existing
container (e.g., add a new mailet to the root processor to pickup messages
from an application, and add a new processor to handle those messages).
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
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
>
>
> Danny,
>
> >>>I also wondered if we should support ajp13
> >>>
> >>>
> >>Do we really need Yet Another Transport Protocol?
> >>
> >>
> ><snip/>
> >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
> >responses.
> >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.
>
> Regards,
>
> - Paul
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
If you go back and look, you'll find that my original proposal was:
> <mailet matcher="Foo[=cond]" class="Bar">
> <matcher-config>
> <tagname>value</tagname>
> </matcher-config>
> <mailet-config>
> <tagname>value</tagname>
> </mailet-config>
> </mailet>
I changed to the prefix approach after discussion with Andrei, reading the
Avalon code, and considering the code already in James. It required the
least changes to how James handles init parameters, and does allow "multiple
conf parameters to matchers." However, if you wish to change James to
expose a full XML configuration to matchers and mailets, that's fine with
me. On the other hand, aren't you trying to keep a simpler interface than
exposing Avalon's full Configuration to matchers and mailets?
We could do something like this:
<mailet class="mailetClass">
<filter class="filterClass1" condition=""/>
<filter class="filterClass2">
<param name="condition">condition</param>
<param name="foo">fooValue</param>
</filter>
<filter class="filterClass3" condition="condition">
<param name="foo">fooValue</param>
</filter>
<param name="somename">somevalue</param>
<param name="othername" value="othervalue" />
</mailet>
which I like best of all the other proposals so far. Mailets must have a
class, but parameters and filters are optional (if no filtering, then it is
ALL). A filter must have a class, but parameters are optional.
I didn't use:
<somename>somevalue</somename>
because if we ever define a DTD we won't want arbitrary names for the child
elements. So <notify>xxx</notify> would be <param name="notify">xxx</param>.
I did show both attribute or child element for parameters; if we want to
pick just one way, I'd go with the child element approach, but sometimes it
is nice to just have a quick self-closing tag.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Monday, June 03, 2002 8:54
To: James Developers List
Subject: Re: Mailet API v2
Noel,
I didn't like the approach you took because you're mixing matcher and
mailet configuration. I think Daniel's is much cleaner since by
configuring things separately, it becomes easier to put 2 or more
matchers/interceptors in front of a single mailet.
As for naming, I don't really care about matcher vs. interceptor... what
about "filter"? I tend to agree with Daniel that "matcher" implies
something simpler and I tend to agree with Noel that "interceptor"
implies something more, e.g. doing something. Since Noel described a
matcher/interceptor as *filtering* the result sets, does that work for
people?
Another thing I like about Daniel's config example is that it allows for
multiple conf parameters to matchers, which is probably overdue.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Noel J. Bergman wrote:
> More later, but I wanted to reply to:
>
>>I believe that matchers should be renamed interceptors and the config
>>changed to look more like this example:
>><mailet>
>> <interceptor>
>> <class>my.package.fooInterceptor</class>
>> <condition>domain=me.com</condition>
>> <otherparam>somevalue</otherparam>
>> <interceptor>
>> <class>my.package.fooMailet</class>
>> <params>
>> <somename>somevalue</somename>
>> </params>
>></mailet>
>
> Please see
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02208.html and
> related messages. According to the scheme Andrei and I discussed, the
> example could be encoded as:
>
> <mailet match="fooInterceptor" class="fooMailet">
> <matcher-config:domain>me.com</matcher-config:domain>
> <fooInterceptor:otherparam>somevalue></fooInterceptor:otherparam>
> <fooMailet:somename>somevalue</fooMailet:somename>
> <mailet-config:othername>othervalue</mailet-config:othername>
> </mailet>
>
> matcher|mailet-config and the matcher|mailet classname are synonyms in
> context, and just used for illustration purposes.
>
> I posted the outline of the code changes necessary to support this right
now
> in James. By now Andrei may have put them in, else I can do them this
week.
>
> And I don't especially care what we call matchers, but interceptor does
not
> carry an a priori semantic meaning to me. If they are going to be
renamed,
> I'd just as soon call them "conditions": <mailet condition="condClass"
> class="mailetClass" />
>
>>the interceptor might poll a remote device or query a database
>>and handle the mail based upon the results.
>
>
> The problem I have with that sentence is that a matcher is not supposed to
> "handle" the mail; it is supposed to yield a filtered set of recipients,
> which the processor will use with the mailet. I know that you know that,
> and quite well, but the words used in your description blurred the
> distinction between matcher and mailet.
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Serge Knystautas <se...@lokitech.com>.
Noel,
I didn't like the approach you took because you're mixing matcher and
mailet configuration. I think Daniel's is much cleaner since by
configuring things separately, it becomes easier to put 2 or more
matchers/interceptors in front of a single mailet.
As for naming, I don't really care about matcher vs. interceptor... what
about "filter"? I tend to agree with Daniel that "matcher" implies
something simpler and I tend to agree with Noel that "interceptor"
implies something more, e.g. doing something. Since Noel described a
matcher/interceptor as *filtering* the result sets, does that work for
people?
Another thing I like about Daniel's config example is that it allows for
multiple conf parameters to matchers, which is probably overdue.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Noel J. Bergman wrote:
> More later, but I wanted to reply to:
>
>
>>I believe that matchers should be renamed interceptors and the config
>>changed to look more like this example:
>><mailet>
>> <interceptor>
>> <class>my.package.fooInterceptor</class>
>> <condition>domain=me.com</condition>
>> <otherparam>somevalue</otherparam>
>> <interceptor>
>> <class>my.package.fooMailet</class>
>> <params>
>> <somename>somevalue</somename>
>> </params>
>></mailet>
>
>
> Please see
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02208.html and
> related messages. According to the scheme Andrei and I discussed, the
> example could be encoded as:
>
> <mailet match="fooInterceptor" class="fooMailet">
> <matcher-config:domain>me.com</matcher-config:domain>
> <fooInterceptor:otherparam>somevalue></fooInterceptor:otherparam>
> <fooMailet:somename>somevalue</fooMailet:somename>
> <mailet-config:othername>othervalue</mailet-config:othername>
> </mailet>
>
> matcher|mailet-config and the matcher|mailet classname are synonyms in
> context, and just used for illustration purposes.
>
> I posted the outline of the code changes necessary to support this right now
> in James. By now Andrei may have put them in, else I can do them this week.
>
> And I don't especially care what we call matchers, but interceptor does not
> carry an a priori semantic meaning to me. If they are going to be renamed,
> I'd just as soon call them "conditions": <mailet condition="condClass"
> class="mailetClass" />
>
>>the interceptor might poll a remote device or query a database
>>and handle the mail based upon the results.
>
>
> The problem I have with that sentence is that a matcher is not supposed to
> "handle" the mail; it is supposed to yield a filtered set of recipients,
> which the processor will use with the mailet. I know that you know that,
> and quite well, but the words used in your description blurred the
> distinction between matcher and mailet.
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
Noel,
I don't like the namespace stuff, I think its unnecessary and doesn't make
the configuration very easy to read.
> And I don't especially care what we call matchers, but
> interceptor does not
> carry an a priori semantic meaning to me. If they are going to
> be renamed,
> I'd just as soon call them "conditions": <mailet condition="condClass"
> class="mailetClass" />
But the interceptor isn't the condition it is the class that performs the
interception of the message, and it "handles" it by passing it to the mailet
which processes the mail.
It is (IMHO) still not necessarily a property of the "matcher" to be either
conditional or perform any matching in order for it to intercept a message
from the pipe for an interested mailet to process.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by "Noel J. Bergman" <no...@devtech.com>.
More later, but I wanted to reply to:
> I believe that matchers should be renamed interceptors and the config
> changed to look more like this example:
> <mailet>
> <interceptor>
> <class>my.package.fooInterceptor</class>
> <condition>domain=me.com</condition>
> <otherparam>somevalue</otherparam>
> <interceptor>
> <class>my.package.fooMailet</class>
> <params>
> <somename>somevalue</somename>
> </params>
> </mailet>
Please see
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02208.html and
related messages. According to the scheme Andrei and I discussed, the
example could be encoded as:
<mailet match="fooInterceptor" class="fooMailet">
<matcher-config:domain>me.com</matcher-config:domain>
<fooInterceptor:otherparam>somevalue></fooInterceptor:otherparam>
<fooMailet:somename>somevalue</fooMailet:somename>
<mailet-config:othername>othervalue</mailet-config:othername>
</mailet>
matcher|mailet-config and the matcher|mailet classname are synonyms in
context, and just used for illustration purposes.
I posted the outline of the code changes necessary to support this right now
in James. By now Andrei may have put them in, else I can do them this week.
And I don't especially care what we call matchers, but interceptor does not
carry an a priori semantic meaning to me. If they are going to be renamed,
I'd just as soon call them "conditions": <mailet condition="condClass"
class="mailetClass" />
> the interceptor might poll a remote device or query a database
> and handle the mail based upon the results.
The problem I have with that sentence is that a matcher is not supposed to
"handle" the mail; it is supposed to yield a filtered set of recipients,
which the processor will use with the mailet. I know that you know that,
and quite well, but the words used in your description blurred the
distinction between matcher and mailet.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mailet API v2
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>>>I also wondered if we should support ajp13
>>>
>>>
>>Do we really need Yet Another Transport Protocol?
>>
>>
><snip/>
>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
>responses.
>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.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Mailet API v2
Posted by Danny Angus <da...@apache.org>.
Noel,
(1st.. that mail was a brain dump of some thoughts I've been pulling
together for a few weeks now, not a clearly defined idea)
> Matchers seem to me to be well-named, except that they can have
> effect, not
> just match. The mailet tag
> <mailet match="matcher" class="mailet" />
> to me is similar to an IF statement. It produces its primary effect by
> returning a filtered recipient list, although it can have side-effects.
I believe that matchers should be renamed interceptors and the config
changed to look more like this example:
<mailet>
<interceptor>
<class>my.package.fooInterceptor</class>
<condition>domain=me.com</condition>
<otherparam>somevalue</otherparam>
<interceptor>
<class>my.package.fooMailet</class>
<params>
<somename>somevalue</somename>
</params>
</mailet>
IMO not only does that give us the ability to specify limitless parameters
for interceptors, but it also clearly indicates that this mailet will
process mail intercepted by the interceptor based upon its [the
interceptors] own config, whether or not there is any kind of matching
operation carried out.
For instance the interceptor might poll a remote device or query a database
and handle the mail based upon the results. That is conditional
interception, but the condition is not in anyway a matching operation on the
mail being processed.
> > use mail headers ...
>
> How does this differ from what is already provided by the
> MimeMessage.setHeader() method?
Technically not, but conceptually if we provide attribute setters and
getters in the interface, and in the implementation use the mailheaders we
are not compelling mailet container writers to use mail headers. We are,
however, providing a "cheap" easy to implement route which is backwards
compatible with existing repositorys.
>
> > I also wondered if we should support ajp13
>
> Do we really need Yet Another Transport Protocol?
Depends, shoot-me-down-in-flames-if-you-like but one use-case I considered
was this..
"A guy has an application which generates content based upon a URL request,
in order to add interactive email functionality he can use ajp13 to recieve
requests for content from a mailet which marshals parameters in a recieved
mail into a request, and creates a reply based on the response of the webapp
server"
And the other way round
"A webbapp marshalls parameters from the user, and other sources, into a
URL, the ajp13 request causes this to be converted into a Mail object and
injected into James' spool. The response would indicate the success of this
operation"
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
responses.
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.
> As for the Servlet API, where do you see the mapping?
See Serge's reply too.
I must admit that having taken a closer look at the newest servlet API that
it would appear that sun have kind of backed off on the idea that it should
be a generic API upon which to build processing blocks for _any_kind_ of
server application, and roped their steer to the saddle of http.
Thus I unreservedly withdraw that suggestion. (football and jubilee induced
madness must be creeping in ;-)
> I'd be more likely to view Mailets perhaps as filters (with a null
> response?) than servlets.
I dont see why the LinerProcessor call to mailet.service(Mail mail)
shouldn't be regarded as a request/response, with either a null response, or
a Mail response which would be the original mail modified by the processing,
and ready for the next step in the processor.
Nor why the SpoolManager in its role as the manager of the LinearProcessors
shouldn't like wise see the call to LinearProcessor.service(MailImpl mail)
as an identical request/response
In fact I believe that it should be possible to have interchangeable process
ors and single mailets such that a processor can contain mailets or other
processors, but I need to work out how the spool would spool & de-spool part
processed messages (in response to callbacks from processors/mailets?).
> I'm not convinced that it is necessary to change the Mailet API to a
> subclass of Servlet API in order to decouple the mailet, matcher,
> processor
> package from the James server code.
This was my bad communication, the de-coupling I believe we need is *not* of
the code, but to a certain extent of the Mailet API as a project, so that we
can have asynchronous progress on james and mailet.
To that end it would be nice to have the Mailet SDK contain a complete
simple implementation which could be used by developers working on the
mailet API, mailet developers, and by users who aspire to add a simple
mailet context to their products.
One benefit of this would hopefully be to deliver a complete, internally
consisistent and "sealed" mailet container that could be used to add mailet
processing to any of James' protocols because it would be capable of
performing autonomously whilst being ignorant of specific implemetations.
(Sun these days deliver complete, or extensive, implementations of a number
of API's in those API's swing's look and feel, and Java Mail are two
examples where you can write a lot of your own implementation, or just use
the one provided)
Ideally if a mail spool manager instantiated this mailet container, it would
have to implement MailetContext, create a Configuration, and nothing else.
And finally a package of mailets and interceptors, with a configuration file
should be able to be unpacked by the container and the processors created
from the resulting files, thus de-coupling mailets and their dependancies
from both the Mailet API and from the mail application platform hosting
them. (of course there still needs to be some indication of the order in
which these applications are requested, but the insertion point
specification would be a single line in James config.xml pointing to the
relevant archive)
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>