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

[Emmanuel <e allaud wanadoo fr>]

On 01.06.2002 01:57 Carlos Morgado wrote:
> On Fri, May 31, 2002 at 06:52:37PM +0200, Emmanuel wrote:
> > 	Hi all,
> > Tim and I was discussing about filters being run upon reception that
> will
> > let deleted messages even if you had checked "hide deleted" or "delete
> > irremediably...".
> > Finally I think this is an issue rooted deeper than filters. For me it
> is
> > the add/delete messages scheme that lacks a coherent notification. We
> 
> This was touched lightly while discussing upgrade path for
> balsa2 the new treemodels.

Oh I'll try to have a look.

> > The way I would do it :
> >
> > 	* all backend messages moving/copying messages and involving a
> > mailbox should send the notification themselves : in fact there is now
> > only libbalsa_message[s]_copy(dest_mailbox,messages) in that case, and
> it
> > should tell the dest_mailbox that it has new messages (sending it the
> > "MESSAGES_NEW" message).
> 
> 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 ?

> > 	* all backend messages moving/copying messages not involving a
> > mailbox should not notify themselves; indeed for example think of
> > libbalsa_messages_delete(messages), their is no garantee that the list
> of
> > messages to delete all come from the same mailbox, so there, this
> should
> 
> imo this is somewhat evil, but neatly correct abstraction wise.
> currently i don't  see a situation were you can delete messages from
> diferent mailboxes but with filtered view that is a possibility

Yes it seems a bit overkill for now, but I have in mind that things will 
get a bit more complicated later so let's do it quite flexible to be able 
to handle all cases later.

> > be the responsability of the caller (which knows about the mailbox[es]
> > being altered) to send the notification (ie send "MESSAGES_DELETE" to
> the
> > mailbox[es]).
> >

> 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)

> > 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.
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.

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.
Bye
Manu