Jason Webb wrote: > > -----Original Message----- > > From: Stefano Bagnara [mailto:[EMAIL PROTECTED] > > Sent: 26 October 2005 17:26 > > To: 'James Developers List' > > Subject: Re: Re: IMAP status > > <snipped> > > > > In my current james (patched trunk) I have this interface for > > MessageRepository: > > > > /** > > * Interface for a Repository to store MimeMessage. > > * > > * > > */ > > public interface MessageRepository { <snipped> > // I'd also add > void delete(); // Remove the repository completely > > void rename(String newName); //move or rename the repository > // Copy is not required for IMAP as it can be > implemented in other > ways > > // I'm fairly indifferent to how we get the child reps > // we just need some way to get hold of them > MessageRepository[] getChildren(); > > void addChild(MessageRepository repository); > > > > }
Would we want a MessageRepository to be able to rename or delete itself at the public interface level? This might be how it happens at the implementation level, but its generally safer and easier to have the parent instigate these actions. This enables the parent to update its references without requiring some kind of eventing mechanism and enbles the enforcement of rules in the context of the parent. The drawback is that we would need a null top node to perform these actions on the root MessageRepository. In truth its hard to come up with a case for either renaming or deleting the root, so I think this is a mute point and no drawback at all. > > There would then be a separate interface for IMAP repositories to wrap > things like access to UIDs and MSNs. Do you mean an interface that extends the basic one described above? If so, I can see us digging a hole for ourselves as we could end up with just some repositories supporting IMAP. I would rather go for a single interface supporting the set of operations we require or a scheme whereby we add getter/setters for generic named attributes, e.g. void setAttribute(String aName, Object aValue) / Object getAttribute(aName). The latter approach would enable any number of additional attributes to be added for any number of repository types. > > > > And then I create a MessageRepositoryWrapper that provide a > > MessageRepository over an "old" (currently used) > MailRepository. This way > > I've been able to upgrade to my interfaces while keeping > the current data > > (file/db structure/data). > > > > The interface is really slim: we just need to decide wether to keep > > "MimeMessage" or use a "Stream" instead. > > Maybe the StreamRepository from cornerstone already > implements a similar > > interface. We already use it in the SMTPHandler to store > the incoming > > message before sending it to the spooler. I don't see MimeMessage and Stream as mutually exclusive, we could have interfaces for each. Stream is a layer below MimeMessage and any other high level layer we choose to introduce. We could implement utility adapters for transforming between each high level layer and the Stream layer. We would have one or more interfaces for high level layers such as MimeMessage and a single low level interface for Stream. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
