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 group. 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. Cheers, -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
