Andy, As Stefano said, the mailet API on the James website don't match what we used. They are a feature of the ASF "content management system." Feel free to laugh at us suckers. That mailet API was actually just a draft, discussed, and abandoned. Some ideas in there are good, and you've highlighted many of them and find others to add.
Comments below. On 8/19/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > So lets start a discussion about making mailet portable and serve > multiple mail servers, yet not hamper performance. It is my thought > that Mailet 2.0 should not reqire compatibility with Mailet 1.0 (because > that limits the field to JAMES since there are parts of Mailet that do > not take portability concerns into acount and frankly I don't want to > implement them if it makes me change the logical structure of JBMS). > Controversially, I would like MailetAPI to not be bound to JavaMail as > that will mean I will need to support two parallel APIs since we will > need to abandon JavaMail internally (meaning also for mailets) for > performance reasons and to better pull off IMAP. Few other points... I would be +1 to Mailet API 2.0 be not backward compatible with Mailet API 1.0. We could repackage these to facilitate the different versions, much how hibernate made the change from version 2 to 3. Once more, I would hope that if the mailet API 2.0 still had all the capabilities of Mailet API 1.0 (not really that hard to imagine), James if it wanted could support mailets that ran were written to the 1.0 spec by a wrapping layer of sorts. > I'd like to see: > > http://james.apache.org/mailet/org/apache/mailet/MailRepository.html > > understand the concept of Folders (which should themselves have attributes) This has been a big hurdle for our IMAP implementation, and somewhat stalling us across the board... we know we need new mail repository, but we want to make sure it supports what IMAP requires. If you have fleshed that out, I figure we can learn from that. > I'd like to see: > > http://james.apache.org/mailet/org/apache/mailet/MailRepository.html#lock(java.lang.String) > > throw LockAqusitionException (documented runtime exception) > > and http://james.apache.org/mailet/org/apache/mailet/MailRepository.html > offer the "boolean supportsLock()" or possibly this should be on the folder. We were hoping to have the locking layer be independent of the MailRepository. That way you could have a queue getting processed by a cluster of James servers accessing a single MailRepository. > I would like to see (though it is possible that I misundersatnd its > function) > http://james.apache.org/mailet/org/apache/mailet/SpoolRepository.html > dropped as it doesn't promote portability (it dictates that hte mail > server must queue and work like JAMES)... > > and replaced with something similar to > > MailetRepository.getQueue(Queue.LOCAL).add(Mail); > MailetRepository.getQueue(Queue.OUTGOING).add(Mail); > MailetRepository.getQueue(Queue.OUTGOING).add(Mail, > Queue.PRIORITY_IMMEDIATE); Yeah, something like that. > I would like to see: > > http://james.apache.org/mailet/org/apache/mailet/MailetException.html > > extend > > RuntimeException. I've come to agree with this approach of extending RuntimeException. > I would like to see the bindings of > http://james.apache.org/mailet/org/apache/mailet/Mail.html to > javax.mail.* broken. JavaMail continues to be broken (especially with > regards to IMAP and its reliance on JAF and its MegaSynchroization > [http://www.jboss.org/index.html?module=bb&op=viewtopic&t=67791 only > some of the discussion/issues caputred]) and we'll likely not include it > in the final release of JBMS 1.0. Sure, alternative discussed below. > I'd like to see the existence of ConfigurationRepository which allows > mailets to generically store/locate values (statistics, etc) > > ConfigurationRepository.find(Class class, key); > ConfigurationRepository.create(Object, key); > ConfigurationRepository.delete(Object, key); > ConfigurationRepository.update(Object, key); I'd rather not have this ad-hoc API stuff... I'd prefer to have an IoC container take care of those kinds of dependencies, unless this is specific to mailboxes attributes or something directly tied. > I would like to see the concept of MailConstructor Mailets. Meaning > most of these mails assume the mail has already been created, I would > like to be able to use mailets to handle the incoming stream. There is work towards a fast-fail process with one Google grant, and there was some thought to how (if) you would reconsile the mailet API and the SMTP stream processing. Might want to follow-up there. One change not mentioned that I wanted was the ability from a Mailet to insert messages in the queue where a mailet is processing. This is somewhat odd and perhaps particular to James... we have linear processors with a series of mailets that optionally fire. Basically like a list of listeners and the spool manager triggers them in order and if the matcher associated with each matches. I would like a way for the mailet API to say, ok, I've massively restructured or split the message I received into 14 different messages, but I want to have them continue processing right after me. The best example of this is a mailing list mailet. Say I'm the 4th mailet in the list. a) If the recipient is not a mailing list I handle, it skips me and goes to the 5th mailet. b) If the recipient is a mailing list I handle, I tweak some headers, change the recipients to match who is subscribed, put a prefix on the subject, and send it on to the 5th mailet. c) If there were 4 recipients and they match 4 mailing lists I handle, then I would want to do what I did in b), except have 4 copies. The cross-posted message would come out of my mailet with 4 different message prefixes and headers and all that, and I would want all to continue to the 5th mailet. Not sure I made any sense... basically instead of adding a message at the top of another queue, add one to where I am in the queue. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
