Re: [RFC] : coherent message add/delete notification

[Carlos Morgado <chbm chbm nu>]

On Sat, Jun 01, 2002 at 02:57:24PM +0200, Emmanuel wrote:
> On 01.06.2002 01:57 Carlos Morgado wrote:

> > 
> > there's also new messages appearing on storage. that's the worse
> > case for notifications
> 
> I don't get it here, what are you talking about please ?
> 

the case where new messages appear on the spool or the imap server
tells us new stuff is there. we need to notify the frontend the index
as been updated

> 
> > messages point back to their mailboxes so it's not actually a problem
> > to raise signals from _delete.
> 
> Yes but this would lead to a storm of notification (one for each message) 
> if you delete a bunch of messages, instead of just one for the whole list 
> (or perhaps one per touched mailbox if there are several involved)
> 
excatly, that's what i mean by 'sticky' :)

> > > Is this OK for everyone, comments?
> > >
> > 
> > it was proposed having LibBalsaMailbox keeping track of the GtkTreeModel
> > that represents it but there may exist filtered views that span multiple
> > mailboxes and multiple views of the same mailbox with diferent
> > sort/threading.
> > so, frontend keeps the Trees and gets notified of changes, but that gets
> > sticky if you delete a bunch of messages that exist on several views.
> > 
> > for me the nicest approach would be to keep a treemodel in libbalsa and
> > then create treemodels for the views referencing that models. i'm not
> > sure
> > how well this would work or muck with gtk internal - some reading must
> > be done.
> > this would get us:
> > * hopefuly, automagic coherency :)
> > * soft and hard views. using some clever (de)referencing we get views
> >  capable of keeping messages alive/deleting messages and soft "readonly"
> >  views
> > 
> 
> I guess we can do it more or less that way (not actually detailed but 
> that's just the basic idea). The backend (in that case the LibBalsaMailbox 
> and the LibBalsaMessage's) is responsible of obeing orders from frontend : 
> delete,move,copy whatever. Datas are changed, and the notification of 
> these changes are sent in the wild (following the scheme I described), 
> that way all views can connect to this notification to keep up to date.
> 
> For example : imagine you have an index open on the mailboxes A and B, a 
> filtered view with messages from mailboxes A,B. OK so the user delete 
> several messages by the index (popup menu, whatever), the notification is 
> sent to : the index itself (and the callback just delete the messages, and 
> even tell the mailbox to actually drop the messages if user pref says to 
> do so), the filtered view also catches the notif and refresh itself if it 
> was displaying part of the deleted messages.

sounds good, the indexes just need to connect to the right mailbox signals

> Now you click on "Check Mail". New messages in A,B --> notif to all views 
> that add them, imagine that view B has a filter on reception that moves 
> matching messages to mailbox C. So there is a notif of deletion for all 
> matching messages of B that are moved to C, and then the index and the 
> view update themselves accordingly. And so on.
> 
optimally, the notifications are only done after all the backend stuff -
views wouldn't even notice B was was touched. unfortunatly this is
harder and even prone to races, we'd need a post_process_notify
or something ran at the very end of all operations we could coalesc

> What I mean is that this scheme it complementary of the GtkTreeModel 
> thing. Perhaps we should just centralize notif to the tree model that 
> repercute them to views depending on the user prefs, but that is just 
> implem. details.

yeah, idealy we would use native gtk+ stuff to do the notifications, but
that's implementation details :)

-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A 
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
My views are my own - but for a reasanoble amount of cash they can be your's
too!