james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: Indestructible repositories
Date Fri, 17 Sep 2004 20:39:54 GMT
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.
> 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.

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

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.


-- Steve

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

View raw message