> Okay, so I guess there isn't really any advantage for us to > spend the time to support this. If a common set of reusable > processor plugins for both servers and standards that authors > can use to assure compatibility for all Mailet 2.0 compliant > servers isn't a realizable goal then I won't spend anymore > time on this. Thanks for listening.
Probably I've not been clear enough. I just think that WE NEED PORTABILITY and a defined set of services to lookup (maybe via JNDI) is needed to increase the number of portable mailets. Isn't JNDI lookup of JDBS datasources a portable operation? Maybe my English is not good enough but I really don't understand how your answer is related with my arguments. BTW, as I wrote in a previous email I think we should agree on the goal of Mailets API before discussing lookups, services, methods, interfaces. Can you provide a list of sample mailets that you think needs to be portable? > > 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 > > -andy
