> what I described didn't require Hibernate nor was it bound to > hibernate. Neither, ASF nor FSF license dogma interests me.. > I just gave a generic object persistence/lookup interface. > Mailets as a spec needs to be portable and using > org.apache.mailet and not getting outside services should be > enough of a generic assurance. If someone wants to write a > non-portable mailet they should have to go outside of the > provided interfaces. > > >I think you two are pretty close... try to abstract every mailet > >related data store so for mailet-related logic there is no database > >code, but then provide some minimal or lightweight way to access > >datasource(s). > > > > > > > No I think the mailet should NOT provide access to the datasource. > JAMES should via jndi. JBMS should via jndi. However if you > do...you risk portability.
Maybe we have totally different concept of portability or I'm not sure I understood you. Are servlets portable? Don't you lookup datasources with JNDI from a mailet? Why should we provide generic object persistence service to a mailet? Are we designing a Mail processing software or a persistence api? IMHO half of the users implementing custom mailets for James DOES use JDBC to lookup custom data or to write/update custom data when a message arrive: if we don't provide a datasource lookup mechanism then we will loose the portability. Currently most james users run custom lookups over the avalon datasourceselector service that our container publish in the context: if we don't provide a standard lookup (like JNDI) they will continue to use that method and JBMS will not be able to run that mailets. Stefano
