Thanks for the great discussion. just 2 small cents thrown in... On 8/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > JDBCVirtualUserTable: DataSourceSelector > > JDBCListServ: DataSourceSelector > > JDBCAlias: DataSourceSelector > > BayesianAnalysisFeeder: DataSourceSelector > > BayesianAnalysis: DataSourceSelector > > > > I do not care to have the mailet exposed to the structure of the > datastore. In fact this may not be a datastore.
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. > > 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. > > 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?) > > That doesn't parse for me. I don't want it to be all that flexible. I > want it to be portable. I do not want mailets to be exposed to the > underlying datasource because that is not as portable, dictates schema, > and requires repetitive configuration (giving sql statements as > config?). I do want mailets to be able to store data in a generic > fashion. For us ConfigurationRepository is likely a limited wrapper > around a Hibernate session ;-). 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. 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). -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
