No worries Ed. I've just written the mbox repository so I've a good idea
what works etc. in James
My only comment is the use of the .select() method. When a user's
repository is opened the method call is .select("username")
To access folders I'd propose the use of .select("username.foldername")
when the server want a folders contents.
Folder links are interesting ;) I'll have a think about those too.
Shared folders are a LOT of pain due to the fact that you'd have a store
the read state for lots of people at the same time. Not nice.
Any comments on this?
-- Jason
> -----Original Message-----
> From: Edward Flick [mailto:[EMAIL PROTECTED]
> Sent: 04 September 2003 17:43
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> Hi Jason,
> Boy and I was thinking about doing it myself, but if you want
> to I am not going to stop you, hehe :-P. Just a note, there
> should probably be folder link files too, right?, if you want
> to be able to have shared message spaces. Do you think this
> is the way to go, also? I'm just tossing out ideas, and am
> open to others.
>
> Ed
>
> -----Original Message-----
> From: Jason Webb [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 04, 2003 11:07 AM
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
> I shall have a think then (and set about doing it)
> DJB's site has a good explanation on how maildir works
> http://qmail.plig.org/man/man5/maildir.html
>
> -- Jason
>
>
> > -----Original Message-----
> > From: Edward Flick [mailto:[EMAIL PROTECTED]
> > Sent: 04 September 2003 15:24
> > To: James Developers List
> > Subject: RE: IMAP Development Pointers
> >
> >
> > Yeah, maildirs seem pretty effective as a store. Thats
> actually what
> > I was hinting at (with a link file instead of real links as
> this is a
> > java program and will be running on platforms which don't
> support real
> > links). I don't buy into the idea that creating multiple
> files will
> > cause much more disk thrashing, as a spool file can be
> scattered all
> > of over the drive too. Although, the open/close efficiency issue is
> > real, BUT I think this can be counteracted with a good
> > full-text index file. Also, thanks to the newer journaling
> > file systems, it would be a lot easier to guarantee that a
> > message is uncorrupted. Although, I definetely think the
> > indexing system should be implemented after a simple maildir
> > implementation is put into place. Anyways, this would just be
> > a step to at least get this into something close to a beta
> > phase. What do you guys think?
> >
> > -----Original Message-----
> > From: Jason Webb [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, September 04, 2003 3:02 AM
> > To: 'James Developers List'
> > Subject: RE: IMAP Development Pointers
> >
> >
> > If there is enough interest or need I will write a maildir-style
> > repository. This is used by qmail and Courier-IMAP to great effect
> > and provides folders etc., and it's safe(ish) over networked file
> > systems. The current repositories are less than ideal other
> than for
> > folder based storage ,particularly the mbox one ;)
> >
> > -----Original Message-----
> > From: Jim Wright [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, September 03, 2003 5:40 PM
> > To: James Developers List
> > Subject: Re: IMAP Development Pointers
> >
> >
> > Hi Edward,
> >
> > I have University of Washington IMAP on my Linux machine
> > and use an experimental format mx which is as you describe.
> To quote
> > the docs:
> >
> > . mx This is an experimental format, and may be removed
> in a future
> > release. ...
> >
> > [snip]
> >
> > mx is somewhat inefficient; the entire directory must be read
> > and each file stat()'d. We found it intolerable for a
> > moderate sized mailbox (2000 messages) and have more or less
> > abandoned it.
> >
> > [snip]
> >
> >
> > There's a general reason why file/message formats are a
> bad idea.
> > Just about every filesystem in existance serializes
> file creation
> > and
> > deletions because these manipulate the free space map.
> This turns
> > out
> > to be an enormous problem when you start creating/deleting more
> > than a
> > few messages per second; you spend all your time
> thrashing in the
> > filesystem.
> >
> > It is also extremely slow to do a text search through a
> > file/message format mailbox. All of those open()s and close()s
> > really
> > add up to major filesystem thrashing.
> >
> > I was not completely convinced by this. File system devices are
> > getting faster for a start.
> >
> >
> >
> ---------------------------------------------------------------------
> > 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]
>
>
> ---------------------------------------------------------------------
> 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]
