james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Webb" ...@inovem.com>
Subject RE: Indestructible repositories
Date Sun, 19 Sep 2004 15:29:50 GMT

> -----Original Message-----
> From: Steve Brewin [mailto:sbrewin@synsys.com]
> Sent: 17 September 2004 21:40
> To: 'James Developers List'
> Subject: RE: Indestructible repositories
> Hi Jason,
> Jason Webb wrote:
> > I'm posting this here rather than the Avalon list because I
> > can't work out
> > if my problem is a James issue due to usage or an Avalon issue due to
> > implementation...
> >
> > It seems that it is not possible to delete or rename
> > repositories. These two
> > features are critical for the IMAP work as both are required
> > features of any
> > IMAP host.
> What are the IMAP use case scenarios which require a repository to be
> deleted or renamed? Knowing what needs to be achieved at a higher level
> might help us to identify the best solution. Besides, I'm curious.
My current implementation for folders involves a repository for each mailbox
in form:
/var/mail/jw <-- INBOX
(You get the idea :))
So when the user deletes or renames a folder the underlying store must be
This may be a stupid thing to do though. It may be easier to store each
mailbox as a separate object in the user's mail repository.
For example the mailbox would contain MailImpl and MailRepository objects as
However, if you delete a user using RemoteManager it only deletes the user
in the user repository. It does nothing with the user's mail on the server
so no matter what I do for the IMAP server the problem with user deletion
still exists.
> >
> > Therefore who should be responsible for deleting/renaming
> > repositories?
> > My current opinion is that this should be done at the Mail Repository
> > interface level and thus the repository implementers issue.
> My take is that it should be the responsibility of the same object that
> creates the repository, rather than the repository object itself.
> Typically
> this should be a singleton manager object.
> In a hierarchy of objects, helper methods are often added to the
> hierarchical elements so that parent objects are responsible for managing
> their children. This is analogous to a file system where we send messages
> to
> a parent directory to create/delete/rename a file within it. Under the
> covers, these methods delegate to the manager. It implies that a root node
> is preconfigured, such as '/' in *nix file systems.
> We should not ask objects "at the MailRepository interface level" to
> destroy
> or rename themselves. This leads to 'ghost' objects in memory which no
> longer represent real objects in the underlying repository. From an OO
> sense
> its wrong as the connected entity should have no knowledge of how it is
> connected and hence should not assume to know how to disconnect itself.
I tend to agree. It just feels wrong in OO terms. 
> Unfortunately, I don't have the code in front of me right now to check if
> we
> are using the manager approach or have any of the elements in place to
> support such an approach.
> One implementation of this approach would be an AbstractFactory,
> "RepositoryManager", which delegates to concrete Factories, one for each
> kind of repository. The operations would include create, copy, move (aka
> rename) and delete. For James cooked repository implementations we would
> have to do all of the work. For other repositories, such as Avalon, the
> concrete "AvalonRepositoryManager" may be able to leverage existing Avalon
> functionality if it exists - it might, I'm no expert. I would ask the
> Avalon
> group.
I think this is what I'm gravitating to. The current James mail repository
usage needs to be re-written to work with IMAP. The current system is fine
for simple POP3 but for the much more rich IMAP protocol its too naïve.
> Not sure if this really helps, and as I've already said, I'm not sure what
> is in the code base. Finally, just to be really helpful, I'm off sailing
> for
> a week from Sunday, so will not be responding immediately to any
> discussion
> this may provoke.
Have a nice time! I'm also on holiday so we can pick this up later :)
> Cheers,
> -- Steve
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message