----- Original Message -----
From: "Serge Knystautas" <[EMAIL PROTECTED]>
> ----- 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.
I can deal with GenericListserv if you can tell me what to do with those
three classes: for me we have to merge them into a single list mailet
(ListManager) without defining new interfaces.
Roberto
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
