You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/01/14 11:23:01 UTC
[Jam3s][RT] Turbine for User Repository?
- crosspost, please keep CCed --
Some thoughts...
Many Apache Java projects have their own user repository and
authentication-authorization system, and this sucks.
Turbine has its own services about this.
Turbine is being Avalonized.
James has it's on system.
James uses Avalon.
James could use Turbine services for this.
Cocoon has it's own system.
Cocoon uses Avalon.
Cocoon could use Turbine services for this.
XXX has it's own system.
XXX uses Avalon.
XXX could use Turbine services for this.
Thoughts?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by Aaron Knauf <ak...@xtra.co.nz>.
Noel has taken the words right out of my mouth.
If JAMES (and this should apply to pretty much any project) is going to
"standardize" on a particular user repository (or any subsystem) then
the operative word in my mind is "standard".
In the case of user repositories, the operative standards are LDAP
(meaning JNDI in the case of java) and JAAS. I would also want to see
the further step of using a standard LDAP schema. I am no expert in
this area, but I believe rfc2256 and rfc3377 address this topic.
Naturally, a facade can (and, IMHO, should) be build on top of the
underlying JAAS/JNDI code to simplify it for authors of client code.
Any effort toward achieving this should, I believe, have a goal of
providing a realistically interoperable single sign-on capability.
ADK
Noel J. Bergman wrote:
> Nicola,
>
> I agree with your and Stefano's basic premise of code reuse, however I would
> also point out that there are already Java standard technologies for these
> sorts of things: JNDI and JAAS.
>
> Beyond the consideration that standards exist, and Turbine isn't one of
> them, there are some technical problems with Turbine.
>
> The Turbine User interface appears to be unacceptable in its current
> incarnation. It is, as is not uncommon for Turbine, tightly tied to the
> Servlet API and it is based upon a static set of bean properties. Both of
> these are critical flaws.
>
> The James project has already tentatively agreed to use a dynamic attributes
> model, which fits with X.500 (JNDI/LDAP) and T-space data models.
>
> If I were not to expose JNDI directly for some reason, such as perceived
> learning curve, I'd consider an EzJNDI-lite layer that used other services,
> such as JNDI itself, underneath. It really would amount to little more than
> a higher level wrapper with simplified interfaces.
>
> Perhaps Quinton McCombs can clarify the picture regarding the apparent
> technical problems with Turbine that would need to be cleared up:
>
> 1) Servlet API inheritance
> 2) Static, not dynamic, attribute set
>
> plus the fact that JNDI and JAAS are the standard technologies implementing
> those features in Java, and there is no indication how Turbine
> uses/integrates those standards.
>
> Clearing those issues by documentation, refactoring, or new code would be
> acceptable. If the Turbine folks want to do it, fine. If not, and Avalon
> wants to do it, fine. If no one else wants to do it, James needs it anyway.
> Again, I agree with the idea of sharing common code, but it has to be the
> right common code.
>
> --- Noel
>
> ref: http://java.sun.com/products/jaas/
> http://java.sun.com/products/jndi/
>
>
> --
> 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: [Jam3s][RT] Turbine for User Repository?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola,
I agree with your and Stefano's basic premise of code reuse, however I would
also point out that there are already Java standard technologies for these
sorts of things: JNDI and JAAS.
Beyond the consideration that standards exist, and Turbine isn't one of
them, there are some technical problems with Turbine.
The Turbine User interface appears to be unacceptable in its current
incarnation. It is, as is not uncommon for Turbine, tightly tied to the
Servlet API and it is based upon a static set of bean properties. Both of
these are critical flaws.
The James project has already tentatively agreed to use a dynamic attributes
model, which fits with X.500 (JNDI/LDAP) and T-space data models.
If I were not to expose JNDI directly for some reason, such as perceived
learning curve, I'd consider an EzJNDI-lite layer that used other services,
such as JNDI itself, underneath. It really would amount to little more than
a higher level wrapper with simplified interfaces.
Perhaps Quinton McCombs can clarify the picture regarding the apparent
technical problems with Turbine that would need to be cleared up:
1) Servlet API inheritance
2) Static, not dynamic, attribute set
plus the fact that JNDI and JAAS are the standard technologies implementing
those features in Java, and there is no indication how Turbine
uses/integrates those standards.
Clearing those issues by documentation, refactoring, or new code would be
acceptable. If the Turbine folks want to do it, fine. If not, and Avalon
wants to do it, fine. If no one else wants to do it, James needs it anyway.
Again, I agree with the idea of sharing common code, but it has to be the
right common code.
--- Noel
ref: http://java.sun.com/products/jaas/
http://java.sun.com/products/jndi/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Jam3s][RT] Turbine for User Repository?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola,
I agree with your and Stefano's basic premise of code reuse, however I would
also point out that there are already Java standard technologies for these
sorts of things: JNDI and JAAS.
Beyond the consideration that standards exist, and Turbine isn't one of
them, there are some technical problems with Turbine.
The Turbine User interface appears to be unacceptable in its current
incarnation. It is, as is not uncommon for Turbine, tightly tied to the
Servlet API and it is based upon a static set of bean properties. Both of
these are critical flaws.
The James project has already tentatively agreed to use a dynamic attributes
model, which fits with X.500 (JNDI/LDAP) and T-space data models.
If I were not to expose JNDI directly for some reason, such as perceived
learning curve, I'd consider an EzJNDI-lite layer that used other services,
such as JNDI itself, underneath. It really would amount to little more than
a higher level wrapper with simplified interfaces.
Perhaps Quinton McCombs can clarify the picture regarding the apparent
technical problems with Turbine that would need to be cleared up:
1) Servlet API inheritance
2) Static, not dynamic, attribute set
plus the fact that JNDI and JAAS are the standard technologies implementing
those features in Java, and there is no indication how Turbine
uses/integrates those standards.
Clearing those issues by documentation, refactoring, or new code would be
acceptable. If the Turbine folks want to do it, fine. If not, and Avalon
wants to do it, fine. If no one else wants to do it, James needs it anyway.
Again, I agree with the idea of sharing common code, but it has to be the
right common code.
--- Noel
ref: http://java.sun.com/products/jaas/
http://java.sun.com/products/jndi/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jam3s][RT] Turbine for User Repository?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola,
I agree with your and Stefano's basic premise of code reuse, however I would
also point out that there are already Java standard technologies for these
sorts of things: JNDI and JAAS.
Beyond the consideration that standards exist, and Turbine isn't one of
them, there are some technical problems with Turbine.
The Turbine User interface appears to be unacceptable in its current
incarnation. It is, as is not uncommon for Turbine, tightly tied to the
Servlet API and it is based upon a static set of bean properties. Both of
these are critical flaws.
The James project has already tentatively agreed to use a dynamic attributes
model, which fits with X.500 (JNDI/LDAP) and T-space data models.
If I were not to expose JNDI directly for some reason, such as perceived
learning curve, I'd consider an EzJNDI-lite layer that used other services,
such as JNDI itself, underneath. It really would amount to little more than
a higher level wrapper with simplified interfaces.
Perhaps Quinton McCombs can clarify the picture regarding the apparent
technical problems with Turbine that would need to be cleared up:
1) Servlet API inheritance
2) Static, not dynamic, attribute set
plus the fact that JNDI and JAAS are the standard technologies implementing
those features in Java, and there is no indication how Turbine
uses/integrates those standards.
Clearing those issues by documentation, refactoring, or new code would be
acceptable. If the Turbine folks want to do it, fine. If not, and Avalon
wants to do it, fine. If no one else wants to do it, James needs it anyway.
Again, I agree with the idea of sharing common code, but it has to be the
right common code.
--- Noel
ref: http://java.sun.com/products/jaas/
http://java.sun.com/products/jndi/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> - crosspost, please keep CCed --
>
> Some thoughts...
>
> Many Apache Java projects have their own user repository and
> authentication-authorization system, and this sucks.
> Turbine has its own services about this.
> Turbine is being Avalonized.
>
> James has it's on system.
> James uses Avalon.
> James could use Turbine services for this.
>
> Cocoon has it's own system.
> Cocoon uses Avalon.
> Cocoon could use Turbine services for this.
>
> XXX has it's own system.
> XXX uses Avalon.
> XXX could use Turbine services for this.
>
> Thoughts?
The day I see this happening I'll be a very happy man.
The concept of converging to one server framework was *exactly* made in
order to allow components to be used across different server applications.
Turbine, James and Cocoon are different beasts, do different things
since they have different goals, but this doesn't mean that pieces can't
be factored out and reused across projects.
I think I can speak for the Cocoon community when I say that if a
Turbine component that does user authentication and authorization gets
avalonized (thus more easily integrated with cocoon), it will something
that will interest us very much.
Personally, I'm willing to help pushing this forward.
Hope this helps.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Jam3s][RT] Turbine for User Repository?
Posted by Stephen Haberman <st...@beachead.com>.
On Tue, Jan 14, 2003 at 11:20:24AM +0000, Henning P. Schmiedehausen wrote:
> Look where Fulcrum and T3 went after they were split off the T2 code
> base. Fulcrum now starts to gather momentum, mainly because the T2
> codebase is nearing a state where it can actually use this stuff.
Agreed, having T2 has a direct user of Fulcrum is important at this
stage of Fulcrum's development.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
James Taylor <ja...@jamestaylor.org> writes:
>It has been decided for the next MAJOR revision of Turbine. Clearly
>there are still some details to quibble over wrt the extent of
>integration, but the decision was made, whether Henning likes it or not.
Well, we don't even know what the next MAJOR release will be
called. Turbine-2, Turbine-3, Plexus, Turbine-NG, whatever. Or on what
code base it will be working. All I want ATM is stopping people to
rush stuff preliminary and create a situation as we had right
post-2.1. It took quite a white to get a working 2.2 out of the
door. And we had Fulcrum and Turbine-3 split off in the meantime which
(till today) did get nowhere.
So this doesn't really give me sleepless nights. Ripping out perfectly
good working stuff like configuration just because "there is something
else we could use" does.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by James Taylor <ja...@jamestaylor.org>.
> I'm sorry that my mail was percieved as a pressure mechanism, it was not
> meant that way. I am trying to make other projects be able to benefit
> features by using Turbine.
>
> I thought that using Avalon for Services was something that was decided,
> please accept my apoligies if it's not the case.
It has been decided for the next MAJOR revision of Turbine. Clearly
there are still some details to quibble over wrt the extent of
integration, but the decision was made, whether Henning likes it or not.
> [...]
> > Look where Fulcrum and T3 went after they were split off the T2 code
> > base.
I think they were both valuable experiments. As someone using T3 in
production I think it has a huge advantage over T2 in that it is vastly
simpler. Summit portends even more so...
So why is the codebase so quiet? Well, I expect because those of us
using it in production are quite happy with it as it is.
Which does not mean it is time to release. It may be a good codebase,
but we all have agreed that moving to an avalon oriented architecture
will have a lot of benefits, so that is the next stage of the
experiment. Johns avalonization of fulcrum is one part of that
experiment, Summit and plexus are another. We're all still just testing
the waters here...
-- jt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by Martin Poeschl <mp...@marmot.at>.
Henning P. Schmiedehausen wrote:
>Nicola Ken Barozzi <ni...@apache.org> writes:
>
>
>
>>Henning P. Schmiedehausen wrote:
>>
>>
>
>
>
>>Since the best system for a user repository is IMHO Turbine, I thought
>>that it could be nice that other projects would start using it instead
>>of making their own. Just that.
>>
>>
>
>I actually agree with you here. But please accept, that Turbine "is
>just not there yet". After we put 2.3 out of the door, then is the
>time we should talk about this and I'm pretty sure that we will find a
>solution working for Avalon _and_ Turbine.
>
>Just give us some time and breathing room. Please. Just a few weeks.
>
i don't think we have to wait for a 2.3 release to start thinking about
future plans ...
martin
>
> Regards
> Henning
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Henning P. Schmiedehausen wrote:
> Nicola Ken Barozzi <ni...@apache.org> writes:
>
>>Henning P. Schmiedehausen wrote:
>
>>Since the best system for a user repository is IMHO Turbine, I thought
>>that it could be nice that other projects would start using it instead
>>of making their own. Just that.
>
> I actually agree with you here. But please accept, that Turbine "is
> just not there yet". After we put 2.3 out of the door, then is the
> time we should talk about this and I'm pretty sure that we will find a
> solution working for Avalon _and_ Turbine.
>
> Just give us some time and breathing room. Please. Just a few weeks.
:-)
Sure. Sorry again for being too quick on this, I'm so excited! :-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Nicola Ken Barozzi <ni...@apache.org> writes:
>Henning P. Schmiedehausen wrote:
>Since the best system for a user repository is IMHO Turbine, I thought
>that it could be nice that other projects would start using it instead
>of making their own. Just that.
I actually agree with you here. But please accept, that Turbine "is
just not there yet". After we put 2.3 out of the door, then is the
time we should talk about this and I'm pretty sure that we will find a
solution working for Avalon _and_ Turbine.
Just give us some time and breathing room. Please. Just a few weeks.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Henning P. Schmiedehausen wrote:
> And please stop "trying to apply pressure". This really annoys me and
> might even start to drive me away from Avalon.
I'm sorry that my mail was percieved as a pressure mechanism, it was not
meant that way. I am trying to make other projects be able to benefit
features by using Turbine.
I thought that using Avalon for Services was something that was decided,
please accept my apoligies if it's not the case.
[...]
> Look where Fulcrum and T3 went after they were split off the T2 code
> base.
Nobody is talking about splitting off anything. It's about being able to
make Turbine the common system for these services.
If you're talking about a common repository for components, well,
real-life has shown me that it's a worthly goal but not a practical one ATM.
Because of this we are discussing about creating an Avalon Components
project, where Avalon will keep its own components. The idea is that
Turbine will keep his, and James likewise. We would make a page that
links to all these components from the Avalon Components site, so that
users that need a feature that is in a Turbine service are redirected to
the Turbine project for it.
Since the best system for a user repository is IMHO Turbine, I thought
that it could be nice that other projects would start using it instead
of making their own. Just that.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Nicola Ken Barozzi <ni...@apache.org> writes:
> - crosspost, please keep CCed --
As I read this via mail2news gate, not easily possible, sorry.
>Some thoughts...
>Many Apache Java projects have their own user repository and
>authentication-authorization system, and this sucks.
>Turbine has its own services about this.
>Turbine is being Avalonized.
This is where your logic breaks down for me, because to me, this
assumption is wrong!
Correct IMHO is "Turbine will use parts of the Avalon lifecycle
interfaces with the idea to be able to run Services in a Container in
the long run".
Everything else is pretty much out of the Turbine mainstream scope
(such as Jasons' work on Plexus) or not even near anything
useful. Read Stephens' posting about configuration. And please _think_
about this.
And please stop "trying to apply pressure". This really annoys me and
might even start to drive me away from Avalon.
By pulling in "more and more projects which demand Turbine to be
avalonized", the only thing you will achieve IMHO, is that you drive
some Turbine developers away until we get a code split. You get an
abandoned but avalonized code base and another, Turbine-based, project
goes on and will harbour bad feelings about Avalon because of
this.
Look where Fulcrum and T3 went after they were split off the T2 code
base. Fulcrum now starts to gather momentum, mainly because the T2
codebase is nearing a state where it can actually use this stuff.
[... every thing else relying on Nicolas' assumption deleted ...]
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> - crosspost, please keep CCed --
>
> Some thoughts...
>
> Many Apache Java projects have their own user repository and
> authentication-authorization system, and this sucks.
> Turbine has its own services about this.
> Turbine is being Avalonized.
>
> James has it's on system.
> James uses Avalon.
> James could use Turbine services for this.
>
> Cocoon has it's own system.
> Cocoon uses Avalon.
> Cocoon could use Turbine services for this.
>
> XXX has it's own system.
> XXX uses Avalon.
> XXX could use Turbine services for this.
>
> Thoughts?
The day I see this happening I'll be a very happy man.
The concept of converging to one server framework was *exactly* made in
order to allow components to be used across different server applications.
Turbine, James and Cocoon are different beasts, do different things
since they have different goals, but this doesn't mean that pieces can't
be factored out and reused across projects.
I think I can speak for the Cocoon community when I say that if a
Turbine component that does user authentication and authorization gets
avalonized (thus more easily integrated with cocoon), it will something
that will interest us very much.
Personally, I'm willing to help pushing this forward.
Hope this helps.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Nicola Ken Barozzi <ni...@apache.org> writes:
>Some thoughts...
"And the background's fading out of focus.
Yes the picture's changing every moment
and your destination you don't know it."
SCNR. With big apologies to Bryan Ferry. Should pull that record out
more often. :-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jam3s][RT] Turbine for User Repository?
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> - crosspost, please keep CCed --
>
> Some thoughts...
>
> Many Apache Java projects have their own user repository and
> authentication-authorization system, and this sucks.
> Turbine has its own services about this.
> Turbine is being Avalonized.
>
> James has it's on system.
> James uses Avalon.
> James could use Turbine services for this.
>
> Cocoon has it's own system.
> Cocoon uses Avalon.
> Cocoon could use Turbine services for this.
>
> XXX has it's own system.
> XXX uses Avalon.
> XXX could use Turbine services for this.
>
> Thoughts?
The day I see this happening I'll be a very happy man.
The concept of converging to one server framework was *exactly* made in
order to allow components to be used across different server applications.
Turbine, James and Cocoon are different beasts, do different things
since they have different goals, but this doesn't mean that pieces can't
be factored out and reused across projects.
I think I can speak for the Cocoon community when I say that if a
Turbine component that does user authentication and authorization gets
avalonized (thus more easily integrated with cocoon), it will something
that will interest us very much.
Personally, I'm willing to help pushing this forward.
Hope this helps.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3]Mailet chaining
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason,
> We would really like to able to chain mailets together in code.
That is exactly what the James pipeline does. Just refactor the pipeline.
If you want, you could put RemoteDelivery into a separate processor, and
just set the mail state.
> The main reason for this is so that our MLM code can directly call the
> remote delivery mailet
There may be some code refactoring in James v3.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3]Mailet chaining
Posted by Jason Webb <jw...@inovem.com>.
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: 14 January 2003 11:20
> To: James Developers List
> Subject: RE: [V3]Mailet chaining
>
>
> surely you can simply put remote delivery in its own
> processor and change the state of mail in your mailet so that
> they are placed in this processor immediately after leaving
> your mailet, where they will be opend by remoted delivery and
> delivered or spooled for retrying.
>
> If this isn't enough why not?
Doh! Yes it is ...
>
> nextly..
>
> in Jamesv3 you will be able to store mail directly in the
> outgoing spool where it can be picked up by remote delivery.
That's good too.
>
> I'd also rather know what improvements you would like than
> how you would like to achieve them.
>
My main issue at the moment seems to be the repository implementations
for spool and outgoing.
* File based - slow and seems to have a massive memory overhead. Also,
the current implementation writes a lot of files into a top-level
directory. This can cause the OS real problems as it attempts to manage
a 100000 file directory (or whatever). Qmail uses directories within the
spool to make this less of a problem. Oh, and the directory cannot, as
of yet, be placed on another disk for performance reasons. Yes you can
do this using mount etc., but that won't help Win2k users very much.
* DB based - faster, but has really serious contention issues with more
than 1 thread doing delivery for example (particularly on MS SQL
Server). I would like to see a JMS implementation (or similar) to allow
multiple servers to deliver from one queue. A cluster if you like.
We don't use user repositories, so I've less to comment on.
> d.
>
>
> > -----Original Message-----
> > From: Jason Webb [mailto:jw@inovem.com]
> > Sent: 14 January 2003 10:33
> > To: 'James Developers List'
> > Subject: [V3]Mailet chaining
> >
> >
> > I can't remember if this has been discussed before, but...
> >
> > We would really like to able to chain mailets together in code. The
> > main reason for this is so that our MLM code can directly call the
> > remote delivery mailet (as I know that all mails WILL be outward
> > bound). This may seem like an isolated example, so I'd be
> interested
> > if anyone else can come up with other uses. Remember I am
> not trying
> > to break the current pipeline, I'm more wanting to increase
> > performance by short-circuiting mail delivery.
> >
> > -- Jason
> >
> > P.S. I believe servlets already do this (not quite sure though)
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:james-dev-> unsubscribe@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: New to the list..
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
I was just trying to contrast between putting the e-mail through the
pipeline vs storing it directly in the user repository, and then suggested
that if there was a desire to skip the pipeline, that it could be a
configuration item.
Yes, sendMail does end up being a call to spool.store() at the end of the
call chain, so the option could be by configuring the repository name. But
at the moment, I don't believe that sending mail is actually *defined* that
way in the Mailet API -- it is just implemented that way by James. That was
behind the comment I made about unifying concepts in James v3.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New to the list..
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Doing a store would bypass the James pipeline. Doing the send
> puts the message through local message processing. This is considered
> desirable. An argument could be made for it being a configuration option.
>
>
>>IMHO, absolutely not... if you want to put it at the top of the
>>pipeline, put it in the root repository, which is always the top
>>of the spool for local message processing.
>
>
> Serge, please clarify your point. The term "repository" is overloaded a bit
> too much for clarity in this context. I am not at all sure that we are
> disagreeing.
>
> FetchPOP inserts mail the same way that the SMTPHandler does, using
> sendMail(). Eventually, sendMail() calls setState(), which specifies which
> processor. It does not store the user's mail directly in the user's
> mailbox.
Yeah, probably are, so just to clarify...
All sendMail(Mail) does is store the mail object in the _inbound_
repository, which out of the box is something like
file://var/mail/spool. So if fetchpop just stored the mail object to
file://var/mail/spool repository, you'd have the same result (mail gets
processed).
You could have this target repository as an optional configuration
setting (as you suggested) so maybe we are agreeing. But since it
seemed you were saying that fetchpop had to do sendMail() to get the
mail processing to happen, I didn't think we were.
--
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: New to the list..
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Doing a store would bypass the James pipeline. Doing the send
> puts the message through local message processing. This is considered
> desirable. An argument could be made for it being a configuration option.
> IMHO, absolutely not... if you want to put it at the top of the
> pipeline, put it in the root repository, which is always the top
> of the spool for local message processing.
Serge, please clarify your point. The term "repository" is overloaded a bit
too much for clarity in this context. I am not at all sure that we are
disagreeing.
FetchPOP inserts mail the same way that the SMTPHandler does, using
sendMail(). Eventually, sendMail() calls setState(), which specifies which
processor. It does not store the user's mail directly in the user's
mailbox.
I do think that we can unify things further in James v3.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New to the list..
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>2) Is there a reason why fetchpop does a send instead of a store?
>
>
> Absolutely. Doing a store would bypass the James pipeline. Doing the send
> puts the message through local message processing. This is considered
> desirable. An argument could be made for it being a configuration option.
IMHO, absolutely not... if you want to put it at the top of the
pipeline, put it in the root repository, which is always the top of the
spool for local message processing. The only reason I can think to not
specify via repository is if you don't want to have fetchpop know where
that repository is (I suppose somewhat of use, but even still doesn't
seem that critical).
>>3) Is anyone else working on something like this or interested in this
>> at all?
>
>
> I think that there would be considerable interest, especially since your
> version now allows us to integrate yahoo and hotmail, amongst other things,
> into James.
Yeah, the Yahoo! mail javamail implementation is pretty cool.
Sounds like it would be good to see your code.
--
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: New to the list..
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Leo,
Would you mind letting me have a look at your FetchPOP version so we can try and combine efforts on this.
You can send it to me offlist if you want.
Thanks, Sergei
----- Original Message -----
From: Leo A. D'angelo
To: James Developers List
Sent: Tuesday, January 14, 2003 10:52 PM
Subject: Re: New to the list..
Thanks Serge,
I actually hand merged your changes into my javamail version over the weekend... This seems to work fine. I just want to make sure that this is the "right" way to solve this problem.... It also got me to thinking on how much control can I get over the mail processing pipeline (admittedly I have not played with this part of james at all). For example it would be best to store messages in an encrypted format and decrypt them as they are "fetched" by their respective protocols (POP, IMAP).... Right now I'm not clear how to do this or if it is even possible...
Thanks for the patch I was headed down a slippery slope before I saw it in the archives ;^)
-LeoD
On Tuesday, January 14, 2003, at 01:42 PM, Serge Sozonoff wrote:
Hi Leo,
I am trying to use fetch(POP,IMAP,etc..) as an equivalent to fetchmail on
linux
then use the mailet's as the equivalent of procmail. Under my current
configuration
if I fetch a mail message that has been sent to more then one person (on
the To line), when I pass the
message to sendMail the other people on the To: line also get a copy of the
message
(this is undesirable) so I was thinking what I want to do is get the
userstore for the intended recipient and
simply store the message. Does this make any sense at all?
I submited a patch on 08.01.2003 which might help you address this issue.
Serge
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
------------------------------------------------------------------------
Leo A. D'Angelo
Chief Technology Officer
j2 Global Communications Inc.
DID: (323) 860-9288
FAX: (323) 372-3522
website: http://www.j2.com/
e-mail: ldangelo@j2.com <ma...@j2.com>
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE8671948
Confidentiality Notice: The information contained in this e-mail and any
attachments is confidential and may also be legally privileged. It is
for the exclusive use of the intended recipient. If you are not an
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this e-mail is strictly prohibited. If you
have received this e-mail in error, please notify the sender and
permanently delete the e-mail and any attachments immediately. You
should not retain, copy or use this e-mail or any attachment for any
purpose, nor disclose all or any part of the contents to any other
person. Thank you.
------------------------------------------------------------------------
Leo's new FetchMessage service (RE: New to the list..)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
> For example it would be best to store messages in an encrypted format
> and decrypt them as they are "fetched" by their respective protocols
You can't control what the far end provides, you IF you detect it as
encrypted (with a matcher) then you can run it through a decrypting mailet.
This is one reason for why you might want to post the message through the
James pipeline rather than directly into a user's repository.
--- Noel
P.S. If you don't mind, would you please make sure that you have turned on
"plain text only" for this mailing address? :-) I don't know where to find
that on whatever Macinoths mail client you're using, but it should be an
option.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New to the list..
Posted by "Leo A. D'angelo" <ld...@mac.com>.
Thanks Serge,
I actually hand merged your changes into my javamail version over the
weekend... This seems to work fine. I just want to make sure that
this is the "right" way to solve this problem.... It also got me to
thinking on how much control can I get over the mail processing
pipeline (admittedly I have not played with this part of james at all).
For example it would be best to store messages in an encrypted format
and decrypt them as they are "fetched" by their respective protocols
(POP, IMAP).... Right now I'm not clear how to do this or if it is
even possible...
Thanks for the patch I was headed down a slippery slope before I saw it
in the archives ;^)
-LeoD
On Tuesday, January 14, 2003, at 01:42 PM, Serge Sozonoff wrote:
> Hi Leo,
>
>> I am trying to use fetch(POP,IMAP,etc..) as an equivalent to
>> fetchmail on
> linux
>> then use the mailet's as the equivalent of procmail. Under my current
> configuration
>> if I fetch a mail message that has been sent to more then one person
>> (on
> the To line), when I pass the
>> message to sendMail the other people on the To: line also get a copy
>> of the
> message
>> (this is undesirable) so I was thinking what I want to do is get the
> userstore for the intended recipient and
>> simply store the message. Does this make any sense at all?
>
> I submited a patch on 08.01.2003 which might help you address this
> issue.
>
> Serge
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
------------------------------------------------------------------------
Leo A. D'Angelo
Chief Technology Officer
j2 Global Communications Inc.
DID: (323) 860-9288
FAX: (323) 372-3522
website: http://www.j2.com/
e-mail: ldangelo@j2.com <ma...@j2.com>
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE8671948
Confidentiality Notice: The information contained in this e-mail and any
attachments is confidential and may also be legally privileged. It is
for the exclusive use of the intended recipient. If you are not an
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this e-mail is strictly prohibited. If you
have received this e-mail in error, please notify the sender and
permanently delete the e-mail and any attachments immediately. You
should not retain, copy or use this e-mail or any attachment for any
purpose, nor disclose all or any part of the contents to any other
person. Thank you.
------------------------------------------------------------------------
RE: New to the list..
Posted by Danny Angus <da...@apache.org>.
yes serge, thanks, it was noted, I'll apply it before the w/e.
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: 14 January 2003 21:42
> To: James Developers List
> Subject: Re: New to the list..
>
>
> Hi Leo,
>
> >I am trying to use fetch(POP,IMAP,etc..) as an equivalent to fetchmail on
> linux
> >then use the mailet's as the equivalent of procmail. Under my current
> configuration
> >if I fetch a mail message that has been sent to more then one person (on
> the To line), when I pass the
> >message to sendMail the other people on the To: line also get a
> copy of the
> message
> >(this is undesirable) so I was thinking what I want to do is get the
> userstore for the intended recipient and
> >simply store the message. Does this make any sense at all?
>
> I submited a patch on 08.01.2003 which might help you address this issue.
>
> Serge
>
>
>
> --
> 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: New to the list..
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Leo,
>I am trying to use fetch(POP,IMAP,etc..) as an equivalent to fetchmail on
linux
>then use the mailet's as the equivalent of procmail. Under my current
configuration
>if I fetch a mail message that has been sent to more then one person (on
the To line), when I pass the
>message to sendMail the other people on the To: line also get a copy of the
message
>(this is undesirable) so I was thinking what I want to do is get the
userstore for the intended recipient and
>simply store the message. Does this make any sense at all?
I submited a patch on 08.01.2003 which might help you address this issue.
Serge
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Leo's new FetchMessage service (RE: New to the list..)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
> If someone can point me towards the instructions on how I can
> contribute what I develop and I am more than happy to share!
Great! :-)
Does this help? http://jakarta.apache.org/james/contribute.html
> I am trying to use fetch(POP,IMAP,etc..) as an equivalent to fetchmail on
linux
Excellent! You might have noticed my reference to Eric's fetchmail the
other week to Sergei. FetchPOP was just a start. Sounds like you're really
taking the ball on it, and that sounds great.
> then use the mailet's as the equivalent of procmail.
Right. That is why you want to put the message into the pipeline. :-)
> if I fetch a mail message that has been sent to more then one person
> (on the To line), when I pass the message to sendMail the other people
> on the To: line also get a copy of the message (this is undesirable)
It appears that FetchPOP uses the wrong variation of sendMail. Please look
at SMTPHandler, and create a Mail object with the correct recipient(s).
Let me explain: Message is the actual message. Mail is a carrier that has a
message, but also other attributes. If you look at the SMTPHandler, you
should see that the message is what we receive from the DATA command, but
the mail object (carrier) has information from the HELO and RCPT TO
commands.
I only glanced at the code briefly, but it looks like a very easy fix. Of
course, if I missed something, Danny will point out my error.
> What I am thinking is that james can collect signatures (or certs)
> and use them to sign and encrypt messages automatically. One of
> the big barriers to encrypting e-mail is the average e-mail user
> does not understand how to do it.
Possibly, but that would be a specific application of the general approach.
In your case, I might want to have James check your e-mail locally before I
get it, because you're using PGP, and I don't want to install the PGP
plug-in for my mail client. On the other hand, let's say that James
verified your identity. We'd have to do something so that when I got the
message from James, I knew that no one had falsely spoofed whatever James
would do to tell me that it had verified your signature.
> Also I was thinking that the "servers" could exchange certs
> with each other and then everything that passes between domains
> is encrypted via s/mime rather than on a user by user basis....
That sort of message exchange could be incorporated into the pipeline.
Fairly straigtforward to do. Point to point communications can use TLS, but
store & forward might benefit from encryption. In any event, once done it
is just a tool.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New to the list..
Posted by "Leo A. D'angelo" <ld...@mac.com>.
On Tuesday, January 14, 2003, at 10:41 AM, Noel J. Bergman wrote:
> Leo,
>
> Welcome! :-)
>
>> 1) Why doesn't fetchpop use javamail API? I have hacked a
>> version that does, and it can be used for pop, imap,
>> nntp or any other javamail transport relatively easily?
>
> I don't know that there is any technical reason not to use JavaMail.
> Your
> version sounds like it would be a welcome contribution.
>
It seemed advantageous in that javamail supports multiple types of
"transports" (POP, IMAP, NNTP, MH, MBOX, etc...) with the same API.
Also providers can be changed "on the fly".
If someone can point me towards the instructions on how I can
contribute what I develop and I am
more than happy to share!
>> 2) Is there a reason why fetchpop does a send instead of a store?
>
> Absolutely. Doing a store would bypass the James pipeline. Doing the
> send
> puts the message through local message processing. This is considered
> desirable. An argument could be made for it being a configuration
> option.
I am trying to use fetch(POP,IMAP,etc..) as an equivalent to fetchmail
on linux
then use the mailet's as the equivalent of procmail. Under my current
configuration
if I fetch a mail message that has been sent to more then one person
(on the To line), when I pass the
message to sendMail the other people on the To: line also get a copy of
the message
(this is undesirable) so I was thinking what I want to do is get the
userstore for the intended recipient and
simply store the message. Does this make any sense at all?
>
>> 3) Is anyone else working on something like this or interested in this
>> at all?
>
> I think that there would be considerable interest, especially since
> your
> version now allows us to integrate yahoo and hotmail, amongst other
> things,
> into James.
>
>> I have been playing around with james for a couple of months with the
>> intention of adding pgp and s/mime encryption/decryption mailet's
>
> Interestingly enough, this very subject came up over the past two days
> on
> james-user. I believe that there will likewise be considerable
> interest in
> such mailets. In normal use, client mailers handle encryption, but
> James is
> also intended for building messaging applications, and thus benefits
> from
> being able to participate in encrypted message exchanges.
>
What I am thinking is that james can collect signatures (or certs) and
use them to sign and encrypt messages
automatically. One of the big barriers to encrypting e-mail is the
average e-mail user does not understand
how to do it. Also I was thinking that the "servers" could exchange
certs with each other and then everything
that passes between domains is encrypted via s/mime rather than on a
user by user basis.... So I am hoping to handle both user level as
well as server/domain level encryption solutions.
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
------------------------------------------------------------------------
Leo A. D'Angelo
Chief Technology Officer
j2 Global Communications Inc.
DID: (323) 860-9288
FAX: (323) 372-3522
website: http://www.j2.com/
e-mail: ldangelo@j2.com <ma...@j2.com>
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE8671948
Confidentiality Notice: The information contained in this e-mail and any
attachments is confidential and may also be legally privileged. It is
for the exclusive use of the intended recipient. If you are not an
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this e-mail is strictly prohibited. If you
have received this e-mail in error, please notify the sender and
permanently delete the e-mail and any attachments immediately. You
should not retain, copy or use this e-mail or any attachment for any
purpose, nor disclose all or any part of the contents to any other
person. Thank you.
------------------------------------------------------------------------
RE: New to the list..
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
Welcome! :-)
> 1) Why doesn't fetchpop use javamail API? I have hacked a
> version that does, and it can be used for pop, imap,
> nntp or any other javamail transport relatively easily?
I don't know that there is any technical reason not to use JavaMail. Your
version sounds like it would be a welcome contribution.
> 2) Is there a reason why fetchpop does a send instead of a store?
Absolutely. Doing a store would bypass the James pipeline. Doing the send
puts the message through local message processing. This is considered
desirable. An argument could be made for it being a configuration option.
> 3) Is anyone else working on something like this or interested in this
> at all?
I think that there would be considerable interest, especially since your
version now allows us to integrate yahoo and hotmail, amongst other things,
into James.
> I have been playing around with james for a couple of months with the
> intention of adding pgp and s/mime encryption/decryption mailet's
Interestingly enough, this very subject came up over the past two days on
james-user. I believe that there will likewise be considerable interest in
such mailets. In normal use, client mailers handle encryption, but James is
also intended for building messaging applications, and thus benefits from
being able to participate in encrypted message exchanges.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Leo's new FetchMessage service (RE: New to the list..)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> To me, it would seem ideal for fetchPOP to be no different to the
> SMTPHandler, from the point of view of the rest of JAMES.
That's the way it is supposed to be. :-)
> I can see the difficulty in having to deal with the extraneous
> recipients of fetched messages, but I wonder if this could be
> dealt with through the use of a (v3) mail attribute?
No new attribute is necessary. The problem is simple. FetchPOP uses the
form of sendMail that takes a MimeMessage, which means that it has to rely
upon the headers, rather than building a Mail object, which already has a
property for local recipients. In other words, what you went on to propose
is already in the code. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New to the list..
Posted by Aaron Knauf <ak...@xtra.co.nz>.
>>2) Is there a reason why fetchpop does a send instead of a store?
>
>
> For the resaons stated by Serge & Noel I wanted fetched mail to be treated
> the same as SMTP delived mail, to gain the advantages of the mailet
> pipeline. Although recent comments suggest that short-circuiting fetched
> mail straight to a single user might be a worthwhile option.
To me, it would seem ideal for fetchPOP to be no different to the
SMTPHandler, from the point of view of the rest of JAMES. I can see the
difficulty in having to deal with the extraneous recipients of fetched
messages, but I wonder if this could be dealt with through the use of a
(v3) mail attribute?
Obviously fetchPOP cannot delete the unwanted recipients, as the real
recipient may wish to see them, but if both the SMTPHandler and fetchPOP
set a mail attribute for the "active recipient", then this could be used
to allow mailets to ignore extraneous recipients and process the mail
with respect to the "active" recipient only. No differentiation between
mail receipt mechanisms would then be necessary.
The down side of this idea is that the SMTPHandler would have to submit
each message to the processor once /for each recipient/. This poses
obvious efficiency problems. This could perhaps be worked around by
allowing multiple "active" recipients for a single message.
An actual field on the Mail interface is probably better suited to this
purpose than a mail attribute, as it would need to be a universally used
mechanism to be of real use. I see mail attributes as being an
extensibility mechanism for use in situations where the attribute is not
universally used.
Any thoughts?
ADK
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: New to the list..
Posted by Danny Angus <da...@apache.org>.
Leo,
> 1) Why doesn't fetchpop use javamail API? I have hacked a version that
> does, and it can be used for pop, imap, nntp or any other javamail
> transport relatively easily?
It doesn't use JavaMail because I was fiddling around with
jakarta-commons/sandbox/net building tests and realised I could quickly add
fetch pop to satisfy the regular requests we get for this functionality.
> 2) Is there a reason why fetchpop does a send instead of a store?
For the resaons stated by Serge & Noel I wanted fetched mail to be treated
the same as SMTP delived mail, to gain the advantages of the mailet
pipeline. Although recent comments suggest that short-circuiting fetched
mail straight to a single user might be a worthwhile option.
> 3) Is anyone else working on something like this or interested in this
> at all?
Fetch pop was added as a by-product of other stuff I was looking at, there
is a demand for it, AFAIK no-one has big plans for it beyond tidying up some
recently raised issues. If you want to look at altering/enhancing it go
right ahead, I'm sure it will be worthwhile.
d.
>
> Thank you in advance,
>
> -LeoD
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
New to the list..
Posted by "Leo A. D'angelo" <ld...@mac.com>.
Hello All,
I thought I would introduce myself to the development list and ask a
couple of questions.
I have been playing around with james for a couple of months with the
intention of adding pgp and s/mime encryption/decryption mailet's
(among other things). In the process of preparing to develop these
mailet's (my intention is to use JCE) I have been playing with
fetchpop. I have a couple of questions about fetchpop specifically
that I would like to pose to the group:
1) Why doesn't fetchpop use javamail API? I have hacked a version that
does, and it can be used for pop, imap, nntp or any other javamail
transport relatively easily?
2) Is there a reason why fetchpop does a send instead of a store?
3) Is anyone else working on something like this or interested in this
at all?
Thank you in advance,
-LeoD
RE: [V3]Mailet chaining
Posted by Danny Angus <da...@apache.org>.
surely you can simply put remote delivery in its own processor and change
the state of mail in your mailet so that they are placed in this processor
immediately after leaving your mailet, where they will be opend by remoted
delivery and delivered or spooled for retrying.
If this isn't enough why not?
nextly..
in Jamesv3 you will be able to store mail directly in the outgoing spool
where it can be picked up by remote delivery.
I'd also rather know what improvements you would like than how you would
like to achieve them.
d.
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 14 January 2003 10:33
> To: 'James Developers List'
> Subject: [V3]Mailet chaining
>
>
> I can't remember if this has been discussed before, but...
>
> We would really like to able to chain mailets together in code.
> The main reason for this is so that our MLM code can directly call the
> remote delivery mailet (as I know that all mails WILL be outward bound).
> This may seem like an isolated example, so I'd be interested if anyone
> else can come up with other uses. Remember I am not trying to break the
> current pipeline, I'm more wanting to increase performance by
> short-circuiting mail delivery.
>
> -- Jason
>
> P.S. I believe servlets already do this (not quite sure though)
>
>
> --
> 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>
[V3]Mailet chaining
Posted by Jason Webb <jw...@inovem.com>.
I can't remember if this has been discussed before, but...
We would really like to able to chain mailets together in code.
The main reason for this is so that our MLM code can directly call the
remote delivery mailet (as I know that all mails WILL be outward bound).
This may seem like an isolated example, so I'd be interested if anyone
else can come up with other uses. Remember I am not trying to break the
current pipeline, I'm more wanting to increase performance by
short-circuiting mail delivery.
-- Jason
P.S. I believe servlets already do this (not quite sure though)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>