Mailing List Archive

dbmail rev 2.0 public folders question
Hi,
I remember a discussion earlier about new database scheme and
public folders.
I am still a bit curious.

/Magnus
Re: dbmail rev 2.0 public folders question [ In reply to ]
On Friday, Oct 10, 2003, at 14:57 Europe/Amsterdam, Magnus Sundberg
wrote:

> Hi,
> I remember a discussion earlier about new database scheme and public
> folders.
> I am still a bit curious.
>
public aka shared folders is something we would still like to
implement. Or rather we still HAVE to implement.

This probably one of those things that we have to implement before
releasing dbmail 2.0

I'd like to make a list of features for dbmail 2.0 that require changes
in the database scheme. I think it would be best to first put in those
features and their database changes, and concentrate on other changes
later.

features that require database change:
* storing headers in messages table
* shared folders
* libSieve support (Aaron Stone)
* changing names in db (messages to message etc)

anybody have any additions?

Ilja

--
IC&S
Koningsweg 4
3582 GE UTRECHT
Re: dbmail rev 2.0 public folders question [ In reply to ]
> features that require database change:
> * storing headers in messages table
> * shared folders
> * libSieve support (Aaron Stone)
> * changing names in db (messages to message etc)
>
> anybody have any additions?

The usermap table, if that feature is adopted (trivial).

There was also another more simplistic filter mechanism
written for dbmail 1.1 in a patch (and reworked in Aaron
Stone's latest posted lmtp patch) - I believe it was thought
there may be application for both, as many people don't need
full libsieve support, just real basic filters. If that
feature were to be added/kept, there has to be some table(s)
to store those filters.

Ryan Butler had started working on a status/capabilities
patch at one time, but was wanting the code changes to settle
down so he didn't have to keep updating it. It would basically
let you enable/disable specific parts (eg. you could enable imap
for just some users, you could disable smtp inbound for a user
and still allow them to clear their pop3 mailbox, etc.). It was
going to be nice and flexible so I could through in my custom
"webmail" capability and only offer webmail access to whom I
want, etc. Very nice feature, and will require some minor
schema changes, which it'd be nice to put in now if they can
be clearly specified.

... I'll hollar if anything else comes to mind.

jn

--
Jesse Norell
jesse (at) kci.net
Re: dbmail rev 2.0 public folders question [ In reply to ]
> > features that require database change:
> > * storing headers in messages table
> > * shared folders
> > * libSieve support (Aaron Stone)
> > * changing names in db (messages to message etc)
> >
> > anybody have any additions?

One more thing - there has been a fairly high interest in
auto-replies/vacation functionality the last couple months, and
it has been noted that it'd be nice to improve upon that somewhat
(eg. to support a vacation functionality similar to the traditional
unix vacation program). That would require a bit of schema change
to facilitate.


--
Jesse Norell
jesse (at) kci.net
Re: dbmail rev 2.0 public folders question [ In reply to ]
On Fri, Oct 10, 2003 at 03:07:01PM +0200, Ilja Booij wrote:
> features that require database change:
> * storing headers in messages table
> * shared folders
> * libSieve support (Aaron Stone)
> * changing names in db (messages to message etc)
>
> anybody have any additions?

I've added an timestamp field named `updated` to messages which allows
purging expunged messages at a much more precise interval (for example,
2 weeks after the message is expunged) than the delete/purge cycle used
by dbmail-maintenance. When using dbmail-maintenance to purge, the age
since expunge is somewhere between time since last delete and time since
last purge.

Please consider making this change to the schema for dbmail 2.

xn