> I would like to know whether this would work..
> re-write Mail as "public abstract class Mail extends MimeMessage"
That doesn't appear to be necessary, nor solve the problem, and keeps Mail a
heavierweight object than it needs to be, which will slow down spool processing.
But let's asssume, for the sake of argument, that we have some MimeMessage subclass to
store in repositories ...
> we write repository implementations we can pass our Mails
> and any repositories we have written can test and cast the
> messages back to Mails and serialise the metadata.
We have clearly expressed requirements to support *standard* repository formats.
Where in the repository would we store serialized meta-data, if those formats don't?
That was the problem I set out to solve with my proposal.
> Noels idea of a meta-data dir is an idea, but what if we're
> using a mix of repository types, including db?
I intended for my proposal to be valid for any JavaMail storage provider that supports
folders. AFAIK, the only one that doesn't is Sun's POP3 store. It implements the
POP3 protocol, which doesn't support the notion. All of the stores that we would use
for local message storage will support subfolders.
> the present repository system may not be great, but it has
> evolved to serve James' requirements.
But it hasn't evolved far enough. It doesn't support IMAP's needs nor NNTP's needs,
and would have to grow into a JavaMail work-alike to do so. JavaMail gives us
tremendous leverage. We just want to address this meta-data issue, and I think we
have a workable approach.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
