Re: Sieve Proposal (Request For Comments)
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 create some unit tests (sample messages and sample sieve scripts) for 1. That could be a separate repository we host. I thought that mailets could be added as sieve extensions, but that may or may not be germane to what you're currently working on. -- Serge Knystautas President Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
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 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, unit test runs to the build process. Doing so would validate that a build is logically correct as well as compilationally correct. > I thought that mailets could be added as sieve extensions, > but that may > or may not be germane to what you're currently working on. I'm purposely not assuming any kind of deployment scenario at this time. This should be usable with any kind of James container or Mailet refactoring that gets done. That said, integration will probably be at the processor level with a 'processor' Sieve Action Command invoking a James processor - which may be a Mailet processor. -- Steve - - - - - - - - - - - - - - - - - - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sieve Proposal (Request For Comments)
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, unit test runs to the build process. Doing so would validate that a build is logically correct as well as compilationally correct. 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. I'm purposely not assuming any kind of deployment scenario at this time. This should be usable with any kind of James container or Mailet refactoring that gets done. That said, integration will probably be at the processor level with a 'processor' Sieve Action Command invoking a James processor - which may be a Mailet processor. I'll need to go through sieve again since you're implementing this (i.e., it may become a reality). I like the idea of sieve as a processor, but could see the per-user processing be within a single mailet. -- Serge Knystautas President Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
> 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 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 MimeMessage interface really expects that at least once you start processing the message, it is memory resident. I'm concerned about performance and scalability with our Sieve implementation. Implementing a MimeMessage subclass that doesn't expect to be memory resident appears to involve largely rewriting the package. Thoughts? With respect to Serge's comment about a separate CVS repository, we could have james-sieve, but 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. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
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 will be independent of James. I'm not fussed how its done. I assume that there are Apache standards for this? > I'll need to go through sieve again since you're implementing this > (i.e., it may become a reality). I like the idea of sieve as a > processor, but could see the per-user processing be within a > single mailet. When they are ready, I will publish the JavaDoc for Sieve's (provisional) interfaces. Then we can bounce around options for the best way(s) to plug into James and adapt the interfaces as required. -- Steve - - - - - - - - - - - - - - - - - - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
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 MimeMessage interface really expects that at > least once you > start processing the message, it is memory resident. RFC3028 defines the commands and tests that 'MUST' and 'SHOULD' be supported, and an extension mechanism for adding non-standard ones. Therefore it specifies the minimum set of operations that a Sieve implementation must support. A useful Sieve implementation would provide a superset of the operations defined in RFC3028. We can expect the range of operations supported by James matchers and mailets to be typical of a useful set. In order not to constrain the range of possible operations, the Sieve implementation will need to expose many aspects of a mail message and it's message store, much as JavaMail does. > I'm > concerned about > performance and scalability with our Sieve implementation. > Implementing a > MimeMessage subclass that doesn't expect to be memory > resident appears to > involve largely rewriting the package. I share your concerns about performance and scalability. Certainly accepting a message in a Stream should be supported. Still, there will be occasions a MimeMessage has already been built, such as in James, so it makes sense to offer this as a means of passing the message too. 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 could be a short or a long discussion. I'll go for the short one as there has been plenty said on the subject of JavaMail already. Sieve's requirements are met by the functionality provided by JavaMail. While JavaMail isn't perfect, its hard to imagine that cooking our own solution would be less effort than fixing JavaMail's imperfections. Yes, that may 'involve largely rewriting the package', but this is still likely to be less effort than cooking our own solution. The benefits of this effort can be reused anywhere that JavaMail is used, including back in James. So, I would prefer a better wheel rather than reinvent one and stick with the JavaMail API. I would be very happy if someone delivered a better JavaMail implementation! > Thoughts? > > With respect to Serge's comment about a separate CVS > repository, we could > have james-sieve, but 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. Neutral about the mechanics. See my reply to Serge. -- Steve - - - - - - - - - - - - - - - - - - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sieve Proposal (Request For Comments)
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 could be a short or a long discussion. I'll go for the short one as there has been plenty said on the subject of JavaMail already. Sieve's requirements are met by the functionality provided by JavaMail. While JavaMail isn't perfect, its hard to imagine that cooking our own solution would be less effort than fixing JavaMail's imperfections. Yes, that may 'involve largely rewriting the package', but this is still likely to be less effort than cooking our own solution. The benefits of this effort can be reused anywhere that JavaMail is used, including back in James. 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. -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sieve Proposal (Request For Comments)
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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
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, Noel's and my own comments on board, I had took a step outside and came up with a solution that will hopefully satisfy all concerns. 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 implemented by this Sieve implementation. The adapter implementation wraps an application's mail message object, such as MimeMessage for JavaMail, MailImpl for James, or a super lightweight streaming object for Noel. The mail message object implements the required functionality in whatever way is most efficient for them. Applications can extend the MailAdapter interface to include the extra functionality their mail message objects support. This extra functionality is exercised by using Sieve's extension mechanism to add new Commands and Tests, specific to the application. RFC3028 mandates that a Sieve script must explicitly declare via the 'requires' Command any extension it will use. As this is evaluated at run time, it is easy to dynamically type-check in 'requires' that the MailAdapter instance is compatible with the method signature of the entity declared as required. Unless I've missed something, this gives a bullet-proof mechanism for supporting any mail messag object and extending the base Sieve functionality to support any number of application specific MailAdapters and their corresponding Commands and Tests without any changes to Sieve's base implementation. As usual, comments are hugely welcomed. Also, any further ideas on where/how I might dump this evolving code-base? I hope to have an alpha release by year end. -- Steve [1] 'MUST' Commands: if, else, elsif, require, stop, keep, discard, redirect 'MUST' Tests: address, allof, anyof, exists, false, header, not, size, true - - - - - - - - - - - - - - - - - - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
> 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 implemented > by this Sieve implementation. Sounds like a Plan, go for it. > Also, any further ideas on where/how I might dump this evolving code-base? I > hope to have an alpha release by year end. Based upon the assumption that you have two tasks to perform: 1/ modify existing James Container to support alternative processor types than "LnearProcessor" 2/ develop a sieve processor I would suggest that you carry out 1 on the HEAD (or the New HEAD once things get swapped around) as it will not only be independant of 2 it will HAVE to be compatible with the rest of James, and will be possible without any external signs (assume un-specified processor declarations are for LinearProcessor etc) 2 could go in contrib, I'd strongly urge you to try (without driving yourself into an asylum) to make this truly a component, such that it can be built, as far as possible, without access to James using only the mailet (and 3rd party) API(s). Where Mailet API changes are indicated bring them back here. This would not only achieve the sieve functionality but pave the way for the development of further alternative processors. Now I'll freely admit that I'm obsessed with component architectures, I like the way that james is assembled from its Big Chunks in an avalon container and can itself assemble mailets into behaviours without programming, I'd love to see this extend to processors too, it would be another, potentially richer, and relatively painless way for 3rd paties to extend James. I'm tempted to resurrect the debate about why processors are not specialized Mailets , but I'll just mention once it and see if anyone has anything new to say. :-) d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
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 processor 70% done. > 2 could go in contrib, 'contrib' where? The sieve processor is currently packaged as org.apache.sieve, though this could change. Its purposely not org.apache.james.sieve as its totally independent of James (and Avalon). > I'd strongly urge you to try (without driving > yourself into an asylum) to make this truly a component, such > that it can > be built, as far as possible, without access to James using > only the mailet > (and 3rd party) API(s). Where Mailet API changes are > indicated bring them > back here. This would not only achieve the sieve > functionality but pave the > way for the development of further alternative processors. This should be relatively simple (I'm probably going to regret saying that). As implemented, the Sieve processor has a very simple interaction with the invoking object. Wrapping it as a component would not even require the Mailet API. Assuming that the scripts were managed by the Sieve component, all the invoking component would need to do would be to pass: - The identity of the script to run - A mail instance to be processed that implements the interface org.apache.sieve.mail.MailAdapter. During evaluation of the mail against the chosen script, the Sieve processor pushes Actions onto a stack within the MailAdapter. On return, the invoking component is expected to perform the Actions on the stack. Actions are things like discard, redirect, fileinto, etc. Things that the invoking component already knows how to do well. Back in James land, the MailAdapters would wrap instances of org.apache.mailet.Mail and we might very well map the Actions to Mailets so that on return from Sieve we invoke them in the order they are on the stack. Still, this related to (1) above, so I shouldn't even be thinking about it yet! > I'm tempted to resurrect the debate about why processors are not > specialized Mailets , but I'll just mention once it and see > if anyone has > anything new to say. :-) Well no takers during the past week or so. Maybe when someone looks at doing (1) above? -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
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 a task list of things to do, and seeing if we could organize people to help on them. > > I'm tempted to resurrect the debate about why processors are not > > specialized Mailets , but I'll just mention once it and see > > if anyone has anything new to say. :-) 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 Sieve language, with its own operations. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
> 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 Sieve > language, with its own operations. Quite right, I agree with all of that, what my question is is why do we continue to support "processor" as disting from "Mailet" when essentially the both have identical lifecycle and service method sigs. I mean, why not make the spoolmanager require mailets as its components, and have Processor mailets to manage further workflow tasks. Then a sieve or forking or distributed proessor could be used wherever a Mailet _or_ a Processor is currently specified, rather than have to choose between one role or the other at design time? I'm not trying to stir up trouble for it's own sake! I'm genuinely interested. Perhaps the compromise might be to write polymorphic components which could fill either role, leaving developers free to tie their component to one role if they chose to? d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
> 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. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
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 current status/plan/pointer for > any open source implementation? > > Thanks much! > - Kirk Hmmm. I guess we should add a pointer in the main James page under subprojects. jSieve exists as a subproject of James and its SVN repository is https://svn.apache.org/repos/asf/james/jsieve. The core functionality is complete and ready for integration into any Java environment, but it hasn't really been tested in the real world. It is designed to be pluggable into any Java code - I use it within a mailet wrapper, I doubt anyone else does. It isn't part of James yet as to be functional it requires a MessageStore to expose a set of operations comparable with those provided by IMAP. Others are working on an IMAP store for James. When this is done it should be a short step to integrate James and jSieve. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sieve Proposal (Request For Comments)
> 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. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
