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 Steve Brewin <sb...@synsys.com> on 2011/12/13 21:18:16 UTC
[jsieve] Is anyone looking at this at the moment?
Hi
Is anyone actively working on jSieve at the moment?
I suspect not as the code in trunk has a hard coded path that is
relative to how things would be in an Avalon deployment -
"..apps/james/var/sieve", so scripts will never be found (unless you
read the source code to
org.apache.james.transport.mailets.ResourceLocatorImpl) and create the
appropriate fie structure.
To be fair, there is a code comment that "This is a toy implementation".
To at least keep this working are there any objections to my changing
the relative path to ../sieve. On a *nix platform I would expect this to
be mapped to a subdirectory of /var, but we don't need to enforce this
in the code base.
Cheers
--Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jsieve] Is anyone looking at this at the moment?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jan 6, 2012 at 7:55 PM, Steve Brewin <sb...@synsys.com> wrote:
> Hi Robert
Hi Steve
> Sorry for the tawdry reply, though I did enjoy my holiday season downtime.
> Wishing you a Happy New Year and I hope your recuperation from the injury is
> complete.
(Good to hear from you again, and thanks for your good wishes. I
expect to continue physiotherapy long term but I now have over 9 hours
a day computer time and no functional impairment which is great :-)
> Thanks for all of the work you have put into jSieve. Due to your efforts it
> is almost time for a full release. There may be a few minor tweaks required
> to enhance its capability to interoperate with ManageSieve (RFC 5804),
> principally advertising its capabilities, but this should not forestall a
> release. We can add them later.
+1
> I'm working on a modular implementation of ManageSieve. The RFC conflates
> the transport mechanism with the application logic. Pluggable modules
> circumvent this by allowing any implemented transport mechanism to be
> plugged in and interact with the application logic module. The application
> logic module interacts with a pluggable repository to store and retrieve
> scripts and state.
Great
> One day, your LocalDelivery mailet modifications will be updated to get the
> active script for the user from the configured ManageSieve implementation.
>
> You say that "I would like to be able to maintain using HTTP". An
> application deployed on a HTTP server (such as a Servlet) could interact
> with a ManageSieve implementation using the RFC defined transport
> protocols.
The mailet side needs a major reworking (as you've probably worked
out). I have training material to prepare this weekend but please
carry on posting your comments and I'll catch up later...
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jsieve] Is anyone looking at this at the moment?
Posted by Steve Brewin <sb...@synsys.com>.
Hi Robert
Sorry for the tawdry reply, though I did enjoy my holiday season
downtime. Wishing you a Happy New Year and I hope your recuperation from
the injury is complete.
Thanks for all of the work you have put into jSieve. Due to your
efforts it is almost time for a full release. There may be a few minor
tweaks required to enhance its capability to interoperate with
ManageSieve (RFC 5804), principally advertising its capabilities, but
this should not forestall a release. We can add them later.
I'm working on a modular implementation of ManageSieve. The RFC
conflates the transport mechanism with the application logic. Pluggable
modules circumvent this by allowing any implemented transport mechanism
to be plugged in and interact with the application logic module. The
application logic module interacts with a pluggable repository to store
and retrieve scripts and state.
One day, your LocalDelivery mailet modifications will be updated to get
the active script for the user from the configured ManageSieve
implementation.
You say that "I would like to be able to maintain using HTTP". An
application deployed on a HTTP server (such as a Servlet) could interact
with a ManageSieve implementation using the RFC defined transport
protocols.
If you have the time and the inclination, let me know.
Cheers
--Steve
On 23/12/2011 13:37, Robert Burrell Donkin wrote:
> On Sun, Dec 18, 2011 at 8:29 PM, Stefano Bagnara<ap...@bago.org> wrote:
>> 2011/12/13 Steve Brewin<sb...@synsys.com>:
>>> Hi
>>> Is anyone actively working on jSieve at the moment?
> Not since University then injury limited my typing time...
>
>> AFAIK, jsieve is used by Zimbra in a non-Avalon environment. I never
>> looked at how they use jSieve, but it worked for them.
> JSieve works well for me, and a release is probably due...
>
>>> I suspect not as the code in trunk has a hard coded path that is relative to
>>> how things would be in an Avalon deployment - "..apps/james/var/sieve", so
>>> scripts will never be found (unless you read the source code to
>>> org.apache.james.transport.mailets.ResourceLocatorImpl) and create the
>>> appropriate fie structure.
>> ResourceLocator is not really "jSieve" but a James Server
>> implementation or the ResourceLocator needed by jSieve and used by the
>> jSieve based Sieve mailet.
> +1
>
> IMHO though the mailet works well enough, the mailet binding needs
> some TLC and would benefit from reworking.
>
>>> To be fair, there is a code comment that "This is a toy implementation". To
>>> at least keep this working are there any objections to my changing the
>>> relative path to ../sieve. On a *nix platform I would expect this to be
>>> mapped to a subdirectory of /var, but we don't need to enforce this in the
>>> code base.
> Having everything under a single root directory improves portability
> but in general, I agree that hard coding is bad. Please feel free to
> dive in and change it.
>
>> It's been a long since I looked at james sources, but I guess the
>> right way would be to use the FileSystem service we already use
>> elsewhere (there is even a TODO in the javadocs for that
>> ResourceLocatorImpl about this).
>> For reference BayesianAnalysis is another mailet that uses the
>> FileSystem service.
> (One day I would like to be able to maintain using HTTP, so that was
> the direction the code was heading in.) Please feel free to dive in
> and change it.
>
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
- - - - - - - - - - - - - - - - - -
This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited.
If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jsieve] Is anyone looking at this at the moment?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Dec 18, 2011 at 8:29 PM, Stefano Bagnara <ap...@bago.org> wrote:
> 2011/12/13 Steve Brewin <sb...@synsys.com>:
>> Hi
>> Is anyone actively working on jSieve at the moment?
Not since University then injury limited my typing time...
> AFAIK, jsieve is used by Zimbra in a non-Avalon environment. I never
> looked at how they use jSieve, but it worked for them.
JSieve works well for me, and a release is probably due...
>> I suspect not as the code in trunk has a hard coded path that is relative to
>> how things would be in an Avalon deployment - "..apps/james/var/sieve", so
>> scripts will never be found (unless you read the source code to
>> org.apache.james.transport.mailets.ResourceLocatorImpl) and create the
>> appropriate fie structure.
>
> ResourceLocator is not really "jSieve" but a James Server
> implementation or the ResourceLocator needed by jSieve and used by the
> jSieve based Sieve mailet.
+1
IMHO though the mailet works well enough, the mailet binding needs
some TLC and would benefit from reworking.
>> To be fair, there is a code comment that "This is a toy implementation". To
>> at least keep this working are there any objections to my changing the
>> relative path to ../sieve. On a *nix platform I would expect this to be
>> mapped to a subdirectory of /var, but we don't need to enforce this in the
>> code base.
Having everything under a single root directory improves portability
but in general, I agree that hard coding is bad. Please feel free to
dive in and change it.
> It's been a long since I looked at james sources, but I guess the
> right way would be to use the FileSystem service we already use
> elsewhere (there is even a TODO in the javadocs for that
> ResourceLocatorImpl about this).
> For reference BayesianAnalysis is another mailet that uses the
> FileSystem service.
(One day I would like to be able to maintain using HTTP, so that was
the direction the code was heading in.) Please feel free to dive in
and change it.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jsieve] Is anyone looking at this at the moment?
Posted by Steve Brewin <sb...@synsys.com>.
On 18/12/2011 20:29, Stefano Bagnara wrote:
> <snipped>
> It's been a long since I looked at james sources, but I guess the
> right way would be to use the FileSystem service we already use
> elsewhere (there is even a TODO in the javadocs for that
> ResourceLocatorImpl about this). For reference BayesianAnalysis is
> another mailet that uses the FileSystem service. Stefano
Sorry, I forgot to respond to this.
I was thinking of something more generic as the repository for Sieve
scripts needn't be the file system. For instance, RFC5804 "ManageSieve"
defines a Sieve management protocol for interacting with a remote server
and the associated URLs.
For now though, switching to the FileSystem service would get things
working, so it's a good interim route.
Cheers
--Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jsieve] Is anyone looking at this at the moment?
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/13 Steve Brewin <sb...@synsys.com>:
> Hi
> Is anyone actively working on jSieve at the moment?
AFAIK, jsieve is used by Zimbra in a non-Avalon environment. I never
looked at how they use jSieve, but it worked for them.
> I suspect not as the code in trunk has a hard coded path that is relative to
> how things would be in an Avalon deployment - "..apps/james/var/sieve", so
> scripts will never be found (unless you read the source code to
> org.apache.james.transport.mailets.ResourceLocatorImpl) and create the
> appropriate fie structure.
ResourceLocator is not really "jSieve" but a James Server
implementation or the ResourceLocator needed by jSieve and used by the
jSieve based Sieve mailet.
> To be fair, there is a code comment that "This is a toy implementation". To
> at least keep this working are there any objections to my changing the
> relative path to ../sieve. On a *nix platform I would expect this to be
> mapped to a subdirectory of /var, but we don't need to enforce this in the
> code base.
It's been a long since I looked at james sources, but I guess the
right way would be to use the FileSystem service we already use
elsewhere (there is even a TODO in the javadocs for that
ResourceLocatorImpl about this).
For reference BayesianAnalysis is another mailet that uses the
FileSystem service.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org