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: Re: IMAP status
Date Wed, 26 Oct 2005 21:02:47 GMT
Jason Webb wrote:
> > -----Original Message-----
> > From: Stefano Bagnara [mailto:apache@bago.org]
> > Sent: 26 October 2005 17:26
> > To: 'James Developers List'
> > Subject: Re: Re: IMAP status
> >
> >
> > In my current james (patched trunk) I have this interface for
> > MessageRepository:
> >
> > /**
> >  * Interface for a Repository to store MimeMessage.
> >  *
> >  *
> >  */
> > public interface MessageRepository {
> // 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message