Hi Serge,
On Sun, 19 Aug 2001 07:01, Serge Knystautas wrote:
> Darrell,
>
> This looks great. Thanks a lot! I'm going to test this weekend to see
> what's left to do. I also like the build approach you used.
Thanks. Unfortunately, I'm not going to have much time in next few weeks.
But, assuming that it's working for you, I'm pretty happy that the
"userstore" proposal is ready to shift onto the main tree. The changes are
pretty pervasive, and it could be a pain to merge later on.
So, here's my
+1 - for moving the userstore proposal into the main tree.
Regarding an alpha release, I think it would be good to get one out soon.
There's still work to do, but as I understand it "alpha" means that we're not
committed to backward compatability. If that's the case, then we should move
on it. Then, we could come up with a release plan built on what Charles
suggested, but break it down into staged alpha and beta releases.
One thing I think needs doing, in both the MailStore and UserStore, is to
include the "sqlReources.xml" in the James.sar file, and get the paths
working properly, so that this file is found relative to the "block path",
rather than the current directory. This is a couple of hours work, maybe as
simple as doing:
JdbcMailRepository.contextualize(Context context) {
File rootPath;
if (context instanceof BlockContext) {
rootPath = ((BlockContext)context).getBaseDirectory();
}
}
Another thing: I'd like to see the RMI proposal in CVS. I'll get onto that
next time I have a few hours, if no-one beats me to it. We should then
migrate the current RemoteManager to use the UserManagement interface. I
think we really need a better management console; maybe the person who was
working on the servlet-based one could help out? (Or someone familiar with
Velocity?)
>
> In terms of configuring whether to store the entire message in the DB or
> the headers in the DB and body in the file, why don't we create two classes
> instead. The db:// would store the complete message in the DB and
> dbfile:// would store only the headers. Perhaps the two implementations
> could extend from a single abstract class so the SQL statements only need
> to get defined once (I'm not sure whether your resource parser handles
> inheritance).
I like the idea of providing an "extends" attribute on an <sqlDefs> element
in the sqlResources file, so that we never have to redefine SQL for similar
components. (An example would be to separate the Spool-specific SQL from the
MailRepository SQL).
Regarding the "db" and "dbfile" implementations: do we need different SQL
statements for the "db" and "dbfile" storage options? It may be simpler to
keep just one set of statements, but set the message parameter to null when
we're using file-storage. (I might be off-track here, though).
It does sound like a good idea to split the implementations for the "pure"
jdbc storage from the "combo" file/db version. This would be cleaner, but
maybe not a high priority. (In other words - up to you...). We should only
ever need a single "filestore" location, so this could be configured for the
repository class as a whole, and specifying "dbfile:" would be all the
configuration required for the different repository instances.
In fact, for starters, you could leave the implementations as-is, and just
add another <repository> config section to the MailStore. Something like:
<repository
class="org.apache.james.mailrepository.JDBCMailRepository">
<protocols>
<!-- the "file/db" storage protocol" -->
<protocol>dbfile</protocol>
</protocols>
<types>
<type>MAIL</type>
</types>
<config>
<sqlFile>dist/conf/sqlResources.xml</sqlFile>
<!-- include a filestore attribute, so that
the repository uses the correct storage option -->
<filestore>file://var/dbspool</filestore>
</config>
</repository>
(and another one for SPOOL)
This would effective do the same thing, at least until we split the
implementations. I can't be sure that this will work, but you could give it a
go. (Oh, we'd probably need to do better parsing of the destinationURL
attribute, since we currently assume a fixed-length protocol).
good luck,
ciao
Daz
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
