> I guess we should add a pointer in the main James page under subprojects.
Yep. And in the great tradition of The Apache Way, if you want something
doing, do it yourself.
(If you need help or advice, on the other hand, just ask.)
d.
Steve Brewin wrote:
> I guess we should add a pointer in the main James page under subprojects.
+1 Please do. :-) That would be a commit to MAIN, BTW. Although I'd like
to raise the issue of migrating to SVN RSN.
--- Noel
Kirk Chen wrote:
>
> Hi, Steve,
>
> We are looking for a java implementation of sieve, and
> I found your message in the james mailinglist archive
> dated 11/27/03. I looked into apache james 2.2.0,
> which doesn't seem to contain any sieve implementation
> code yet.
>
> Could you tell me the curre
> I may get to that. I was thinking of starting a task list of things to
do,
> and seeing if we could organize people to help on them.
Suits me, I've just faxed off new CLA's to cover me in my new job, so I'm
wondering what to look at first. :-)
d.
> LinearProcessor is the familar matcher/mailet flow. Another processor
type
> could implement a newer configuration scheme; an approach I seem to
recall
> you favored. Some other processor type could conceivable provide
> distributed container support. Steve's SieveProcessor implements the
Steve Brewin wrote:
> Danny Angust wrote:
> > 1/ modify existing James Container to support alternative
> > processor types than "LnearProcessor"
> I am rather hoping that, perhaps in vain, that someone else might take
this
> on while I do (2) below.
I may get to that. I was thinking of starting
Danny Angus wrote:
Hi Danny,
Sorry for the delay in replying.
> 1/ modify existing James Container to support alternative
> processor types
> than "LnearProcessor"
I am rather hoping that, perhaps in vain, that someone else might take this
on while I do (2) below.
> 2/ develop a sieve processo
> The Sieve implementation will expect a mail message that implements a
> MailAdapter interface. The MailAdapter interface specifies the minimum
> functionality required to implement the Commands and Tests that RFC3028
says
> a Sieve implementation 'MUST' implement[1]. All of which will be
impl
Serge Knystautas wrote:
>
> I would agree to use JavaMail as well. IMHO, let's just stick to one
> API, and when we're ready to roll-our-own to improve
> performance, then
> all our code using JavaMail can benefit instead of just the Sieve
> proposal or just this or that.
Taking both Serge's, Noe
Noel J. Bergman wrote:
... please be aware that sometime next year, we will be
switching from CVS to Subversion, and probably all ASF code will reside in a
single SVN repository.
Gak! Just when I bought a $25 book on CVS.
-
To
Steve Brewin wrote:
The key question is should the Sieve implementation use MimeMessage and
other JavaMail classes and interfaces internally, use other pre-existing
ones or should we cook our own? Well, I don't know of any pre-existing
alternatives, so lets stick with JavaMail v cook our own.
This
Noel J. Bergman :
> I assume that you meant MineMessage.
No, MimeMessage!
> I am leaning against
> using MimeMessage
> for specific reasons. Please review in detail the RFC 3028
> operations.
> *If* we can implement them against a Stream, I think that we
> would be better
> off because the MimeMe
Serge Knystautas wrote:
>
> I mean the whole Sieve codebase (that is independent of the
> server) be a
> separate CVS repository. I agree we should keep the tests with the
> source code.
Sorry for thinking otherwise! A separate home for Sieve seems logical as its
developement and release cycle wi
> here is a proposal on how to implement Sieve.
> 1) Implement a Java implementation of Sieve that...
> a) Accepts a script read from a java.io.InputStream and a
>javax.mail.internet.MailMessage as input.
I assume that you meant MineMessage. I am leaning against using MimeMessage
for
Steve Brewin wrote:
Not sure about the need for a separate repository though. Personally, I
would rather see this as part of the source in the current repository. This
enables the tests to be maintained and distributed in sync. with the source.
Ultimately, I would like to add these, and many other,
Serge Knystautas wrote:
>
> I think it would be helpful to create some unit
> tests (sample messages and sample sieve scripts) for 1. That
> could be a
> separate repository we host.
Yep! I'm driving this through JUnit.
Not sure about the need for a separate repository though. Personally, I
woul
Steve Brewin wrote:
Following on from the discussions in the "Future Directions" thread, and in
particular the final part of
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
.org&msgId=1146701, here is a proposal on how to implement Sieve.
Sounds great to me. I think it would be helpful to cre
17 matches
Mail list logo
