----- Original Message -----
From: <[EMAIL PROTECTED]>
> Ease of setupwill lure prospective users. If an admin has to
> download extra stuff and fiddle around with different things
> they are less likely that they are going to use it. Putting
> database inside makes it a little more easier and they can
> preview it real easy. If they want to run an industrial
> scale mail server they have to do the extra run around but
> those who are just checking it out don't.
I recognize that if we do a good job, it will be easy for prospective users
to run JAMES out of the box, and I agree this is a top top priority. ;)
Right now you can startup JAMES right away without any complicated setup
(you have to specify your DNS servers), and it works against the file system
just fine. What does hsql give us that the file system doesn't right now?
I don't know what it gives us for spool repositories and POP3 account
repositories. Perhaps for new repositories (that have not been implemented)
that allow searching across headers, either for a mail archiving systems or
for future IMAP4 folders. I thought the embedded database might help with
robustness, but if the field limit is 32k and we still have to save the
message bodies to the file system, it doesn't remove the risk that a message
gets corrupted in a spool by a crash during a save.
Anyway, I hope I'm not coming off too irrational. Just want to know what it
will give us I guess, and I want to release a version 1.2 a.s.a.p.
I committed the database stuff late last night... POP3 accounts tested and
working, and tested against sql server and mysql. Wanted to do postgres but
it doesn't seem to support binary datafields, and was going to put off doing
the hsql script/howto until we know we can store >32k in the database (if
that is a hardfast limitation, we'd need a different approach to the
database repository, like the one Pete did).
This database repository is a first of many possible db repositories, and
this is the simplest one geared primarily towards spool repositories and
POP3 accounts. The sender and recipient (and other meta info in the Mail
object) are stored as separate fields, but the message itself is stored
completely in one field. We can have new others kinds of database mail
repositories in addition to this one for more searchable mail repositories,
and ones that build foreign keyed relationships for replied messages. But
those mail repositories would be slower for storage and retrieval, so I
rationalized that this simpler one is useful to keep around for the spooling
if nothing else.
I've got to clean up a couple spots in the code I know of (better
MailAddress parsing, finishing off the GenericListserv mailets, build an
autoresponder mailet for the error spool), but hopefully we can release
pretty soon. Let me know how well everyone feels the documentation is... I
use Town all the time so I'm afraid I've missed documenting things that most
people (non-town users) do not know.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
