> -----Original Message----- > From: Steve Brewin [mailto:[EMAIL PROTECTED] > 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 /var/mail/jw.Trash /var/mail/jw.Sent /var/mail/jw.Draft (You get the idea :)) So when the user deletes or renames a folder the underlying store must be removed. 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 children. 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
