> >>These are neither portable or schema independent > (ultimately). They > >>can be replaced by more generic interfaces. > >> > >>I would like to see: > >> > >>http://james.apache.org/mailet/org/apache/mailet/MailetContext > >>.html#sendMail(org.apache.mailet.Mail) > >>http://james.apache.org/mailet/org/apache/mailet/MailetContext > >>.html#sendMail(org.apache.mailet.MailAddress,%20java.util.Coll > >>ection,%20javax.mail.internet.MimeMessage) > >>http://james.apache.org/mailet/org/apache/mailet/MailetContext > >>.html#sendMail(org.apache.mailet.MailAddress,%20java.util.Coll > >>ection,%20javax.mail.internet.MimeMessage,%20java.lang.String) > >>http://james.apache.org/mailet/org/apache/mailet/MailetContext > >>.html#sendMail(javax.mail.internet.MimeMessage) > > > > > > All 4 existing in the current mailets. > > > > > > sorry I meant I'd like to see them removed.
How will you send new mails from a Mailet? > > [...] > > There is no MailRepository in the current Mailets, we > should discuss > > how to reintroduce it and what we precisely need. > > I'm planning to create a report with services used via > avalon lookup > > by current james mailet to resolve issues not resolvable > via API so we > > have a scenario to think about. > > > > That's too bad. We actually have a very similar concept. > I'm not yet 100% how to pull off a generic version of our > concept of essentially "MailRepository" and "BodyManager" > (slightly different names) as We stream the body direct to > the database and hte mail repos has a pointer to the mail. > (result: No OOME or crazy GC stuff goes on) > > That would be good. Here is the current services looked up from our bundled mailets: AbstractStorageQuota: MailServer / UserStore ToRepository: Store (just needs to write a MailRepository) RemoteDelivery: Store (just needs to read/write a SpoolRepository) FromRepository: Store (just needs to read a MailRepository) JDBCVirtualUserTable: DataSourceSelector JDBCListServ: DataSourceSelector JDBCAlias: DataSourceSelector BayesianAnalysisFeeder: DataSourceSelector BayesianAnalysis: DataSourceSelector CommandListservProcessor: UsersStore CommandListservManager: UsersStore AvalonListservManager: UsersStore AvalonListserv: UsersStore As you can see we need to provide to the mailets: - datasource services - repositories (read/write) - usersstore (authentication/mailing list management) > >>I'd like to see: > >> > >>http://james.apache.org/mailet/org/apache/mailet/MailRepositor > >>y.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. > >> > >>I would like to see (though it is possible that I misundersatnd its > >>function) > >>http://james.apache.org/mailet/org/apache/mailet/SpoolReposi > tory.html > >>dropped as it doesn't promote portability (it dictates that > hte mail > >>server must queue and work like JAMES)... You probably missed how James works. Your proposal LOCAL/OUTGOING is too much limited. I could agree that we only need 1 interface (Currently you can create a spoolrepository from a mailrepository by adding a wrapper that add the accept services). I would also add more filters capabilities to the current MailRepository interface or we will never gets performance. > >>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); > > > > > > Mail and Spool repositories are no more part of the current apis. > > BTW I don't agree with the concept of named queue (Queue.LOCAL, > > Queue.OUTGOING). > > We never spoke of Priorities: can you elaborate on this? > > > > This is something Postfix and other MS have. You know how > obnoxious poeple always mark their messages as "important" or > "very important" -- some mail servers have rules that result > in those being sent in a thread rather than queued. We'll > probably need this for some mailets (mailisteners for us ATM). > > The "named queue" isn't really a "name" so much as a > distinction between mails that are queued to be processed to > go out or queued to be sent in. > Out mail listener chain is called from the data command and > then queues mails. Shortly we'll have another chain called > from the actual queue processor. What makes sense to you as > a designation to send mails to local users or external? We can easily use Mail priority headers of use multiple spoolers with different priorities provided by the container. I already use multiple spooler in my james so to have different queue with different priorities and I move mails around via a ToSpoolRepository mailet. IMHO there is no need of "priority" concept in the Mailets API: you can simulate this behaviour with a good configuration and current services). > >>I would like to see: > >> > >>http://james.apache.org/mailet/org/apache/mailet/MailetExcep > tion.html > >> > >>extend > >> > >>RuntimeException. > > > > > > I think we should vote about this. > > Can you provade a sample usage where this change is useful? > > Shouldn't the Mailets run inside a container? Can't you catch the > > MailetException and rethrow a RuntimeException? > > > > a container can catch a typed runtime exception. Sometimes > it is useful to run mailets inside of other mailets. As a > whole many java developers think Microsoft was right to drop > checked exceptions from Java3^M^M^M^M^MC#. I'm not so dead > set but prefer not to deal with them at the system level. Well the container MUST catch the static exception. I'll agree with the use of a Runtime exception when you provide an example where the container needs to NOT CATCH the MailetException. > > > >>I would like to see the bindings of > >>http://james.apache.org/mailet/org/apache/mailet/Mail.html to > >>javax.mail.* broken. > > > > > > Currently the Mail interface has the getMessage and setMessage that > > are > > MimeMessages: how would you like to handle this? > > > > Directly handle the pieces and mime stuff. We are > investigating switching to Ristretto > (http://columba.sourceforge.net/). I'm suggesting > incorporating a similar interface and not Ristretto itself > (thus we can use Risretto under the covers if we like). This > would be more appropriate for efficient MIME altogether > (though I'm admittedly slightly removed from some of the > IMAP/MIME crap this is the consensus in our little group). I would use a Stream instead of the MimeMessage, leaving to specific mailets the MimeMessage creation work. We should probably provide a way to cache the MimeMessage associated with a mail stream. And what about MIME4J? > >>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); > > > > > > Can you bring an example usage? > > Is the configurationRepository unique per > Mail/Mailet/MailetContext ? > > > > Baeysian filters, HAM, statistics keepers.. > > Good point. Get from MC but specific instance issued per > mailet class or config'd instance: > > MC.getConfigurationRepository(); //gives a CR for THIS mailet > others will get an instance specific to them > > My Baeysian filter thingy might stick in/get its pattern crap. IMHO a generic ConfigurationRepository will never perform enough or will be never flexible enough. I would limit our effort in providing a container managed DataSources (JNDI lookup as in J2EE?) Stefano
