----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]>
> > I want to expose javax.sql.DataSource's via JNDI so matchers/mailets ... > > Do we really want to require JNDI in the Mailet API? If you say yes, I > won't grouse, but it will open the door to a lot of stuff. If you say no, > then we'll need an alternative way to pass the DataSource (which I agree > with you about, btw). Another task for v3 is migrate to the JNDI DNS service provider. I'm always a fan of using standard implementations, but the BIG benefit is that as of 1.4.1, the JNDI DNS service provider can get the underlying machine's DNS configuration information... imagine not having to tell people to set their DNS servers before starting James. :) So, then we have JNDI included (although it's bundled with JDK 1.4 onward). We could of course use the Avalon naming structure that provides contexts so that james.sar could exist with other server apps and not hit naming conflicts. But I think JNDI is better understood and would be more portable to mailet developers... most servlet apps now expect to get datasource objects using JNDI. I might be missing something, but we would just bind the datasource to the in-memory initialcontext. > > Related to this, I am thinking through a VERP gateway... > > <<grin>> Would you believe that early in my discussions with Brian, > predating the posting of his requirements to infrastructure@, one of his > comments was "We would *really* need ezmlm-equivalent functionality, with > VERP bounce handling and all that." :-) Well certainly we need a real mailing list that has to support VERP. This though was to allow other people sending lots of messages to track who was able to receive what message. > Having a JDBC database as a known part of the environment is getting better > and better. Heh, sure. Ok maybe we do this at least for configuration stuff. I know embeding hypersonic (?) is something you'd like to see. > > > - Security > > What do you mean by security? > > My notes say "base code, mailet loaders, sockets, file directories, etc.", > so I believe that my intent was that James not require a wide open security > policy, but would be able run with the Java 2 security manager enabled. > > Related to that, the Mailet security line item was to suggest that Mailets > not have free run to do whatever they want. This seems important to me as > we open the door to third party classes. I think it would be nice to provide this as an option, but I think in practice it isn't so great. The same thing happened when servlet engines started getting built... people didn't want to run servlet code that could dropped into the server in a free context. But for most users, they want complete flexibility, and it's only in certain installations/businesses that want/need this kind of serverside restrictions. Again, don't mind the feature, just wouldn't want to see it on by default. > > ** Message repository directory structure > > Hmmm ... I agree with the premise of why, but I'm not sure about the how. > Seems overly complex, but maybe I'm reading something into it that isn't > there. > > If we're going to have User attributes, then why not associate a repository > directly with the user? This would provide flexibility, and given the > presence of a tool for copying between repositories, seems to provide a nice > admin capability. And an admin can switch repository types without > accidentally screwing up existing users, OR migrate users to another > repository type. > > What do you think of handling mail repositories that way? Tying repository implementations to mailboxes only solves a small part of the mail management that admin's need. An admin will want to move messages... - from spool, - to a deferred-delivery spool, - to a catch admin mail box, - to a spam holding container, - from a remote imap server, - from that mailing lists holding bin from unsubscribed addresses - to this local delivery queue - from this spool of messages with attachments to scan for viruses All these could potentially be different implementations, spool potentially local file for raw performance, spam in some shared network file store, inboxes in a database, etc... Anyway, so this can't be driven from the user repositories. Serge Knystautas Loki Technologies http://www.lokitech.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
