Serge Knystautas wrote:
Thanks for the great discussion. just 2 small cents thrown in...
I would take these examples as custom apps that you would not
abstract, at least not across many mailet containers. For me, I would
want to see some suggested strategy for accessing a DataSource.
Well if the mailets don't tend to be portable then this kind of puts the
value of implementing this rather low. You should
have to go outside mailets to get at that stuff (maybe jndi or something).
And what about MIME4J?
Okay. What about it?
MIME4J is still only a read-only API. If you've haven't taken a look
at it, it might interest you as you might see a way to make it
read-write. But as is, it's not a feasible replacement to JavaMail.
yeah I think we are looking at it but right now we're ripping out
javamail and replacing it with rosiretto. (Mike just
started that today).
This gets to my distinction above... there is designing a portable
database schema for mailet-related issues like users and mail
repositories and whatever else is decided. Then there is custom
database logic that every 3rd mailet author will ask how he/she should
access a database. We wouldn't want to impose Hibernate on all mailet
authors, ASF licensing issues aside, I just don't think the mailet
container should be dictating database interface for custom database
needs.
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.
Okay I'll look at the latest mailet stuff and then get back.. I may get
latent this week and next as I'm going to Japan next week.
-Andy
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.
