Re: [HACKING] Mailbox tree rewrite

[Pawel Salek <pawsa theochem kth se>]

Thanks for you comments, I have some replies to them, too.

W 2000.11.16 18:55:39 +0100 Ian Campbell napisał(a):
> One quick comment first though: You have abriviated some of the names, I
> think that was just for clarity here - I personally much prefer to spell
> stuff out in full in code.

I abrevviated only in the mail, didn't intend to abbreviate in code.

> Anyway, when I was considering the whole thing some time ago, I thought
> about expanding a LBMailbox to have a list of children. I didn't intend
> to make any distinction between "Sets" and "Leaves" as you have, but
simply
> said that a mailbox with no children was a leaf. My thinking was that it
> was simpler, and also it allows things like the IMAP implementation to
> represent both IMAP directories and the folders within them.

I think it needs to be done for very simple reason: Sets don't have list of
messages, in general provide none of the operations we have for real
mailboxes.

> I was also intending to have some sort of "my list of children changed"
> signal which could be emmited, for example when a new folder is detected.

Sounds good.

> In scheme B you mention that each Leaf would reference a LBMailbox, this
> sounds much like the purpose the current LBServer objects are supposed to
> fullfill, I was thinking that a subtree of Mailboxes from an IMAP server
> would all reference the same LibBalsaServerIMAP (or whatever) which would
> provide much of the actual functionality I guess.

Yes, I meant that too (but probably didn't express that clearly).

> I don't like the idea of having the mailboxes know how to insert
> themselves into a GtkCTree (or whatever) because I think it breaks the
distinction
> between the GUI and the backend stuff (which I would like to keep
> separate). It should not be necessary anyway, because the GUI code can
> simply walk a mailboxes children and do the insertions and then hook to
> the children-changed signal to keep track of updates.

Well, I agree mailboxes should not insert themselves into GUI tree. I meant
rather GUI MailboxNodes. Anyway, it's more like an organization issue,
isn't it?

> I'm also not convinced about having the mailboxes return widgets to edit
> themselves, again it breaks the distinction between GUI and backend. I
> don't think the current way of doing stuff would be too bad if we cleaned
> it up a bit (well, a lot). 

Again, not mailboxes. Mailbox nodes. I think this is the reason why we
should have spearate object for real things like mailboxes that wrap around
file/backend functions and separate mailbox tree nodes that provide GUI
functions. I want to make it as general a possible (and still reasonable)
so we don't need to go through whole code to find where we mention IMAP
mailboxes and their attributes. Although I admit, I could live without this
object-oriented sugar to some extent...

> We already have save/load conf, and I like it a lot...

It would be almost identical to the present one, just rehashed and made
more structural: the imap folder code doesn't fit nicely to present mailbox
configuration scheme, I have tried it.

> One other thing was that I was thinking it might be worthwhile to
> separate the interactive mailboxes (ie Local ones and IMAP) from the
'download
> only' (POP3 and potentially IMAP too), since the two concepts are quite
> different. Perhaps a new hierarchy based around 'LibBalsaMailSource' or
> some such...

Yes, that sounds good...


> The other thing I would like to do is to make each of the 3 local mailbox
> types be a separate object, and require the user to create mailboxes of
> the appropriate type, this would save all sorts of confusion with
detecting
> the type of a mailbox, and would potentially allow su to take advantage
of
> the benfits of the different types of mailbox in a cleaner way. (eg
checking
> for new messages in a maildir..)

Yes, this is a good idea as well. And this is one more reason to try to
break with present switch(mailboxe_type) oriented way of configuring
mailboxes, IMO, it becomes messy, and if we add creating remote IMAP
directores, it will become even more messy. MY point is to introduce as
much symmetry in handling different mailboxes as possible (and plausible).
We really do need symmetry in handling local mailboxes/dirs and IMAP ones,
otherwise IMAP support will be always crippled.

Thanks for your comments! 

Pawel

-- 
-----
Pawel Salek, pawsa@theochem.kth.se