Re: [evolution-patches] Unified Attachment Bar Patch

[Harish Krishnaswamy <kharish novell com>]

Srini,


> > You can just create a file stream and write directly to it, you dont
> > need any intermediate memory objects, or even redundant copies of same.
> > 	
> > Other than that - the attachment bar and attachment object methods seem
> > a bit odd.  there seems to be a strange mixture of funtionality spread
> > across the two objects.
> > 
> i too agree with point. I needs simplification to a greater extent.
> But since im tied up
> with the attachment bar stuff and the freeze is just there, can we do
> this
> bit later in the cycle, unless there is some serious functionality
> issue. If so, 
> i would love to fix them right now. 
Guess the rewrite to create a file stream and writing directly to it
should be straightforward and can be done right away.

> > I suggest you simplify the attachment-bar greatly, and only let it
> > add/remove e-attachment objects, and get the selection.  I dont tihnk
> > you need any of the add attachment type helpers.  The e-attachment
> > object should contain all of the remote-downloading code too - it is the
> > one which is managing a specific attachment.  It can contain all of the
> > editing code too.
> > 
> > That should simplify things a bit overall, even if you might need to
> > change more of the using code (although only in small ways).
> > 
> >  Michael
> > 
I agree. Pl. take this up right *after* the 2.3.5 release. I would like
you to commit this (with the leak fixes you mentioned above) - to make
it to the feature freeze and refactor it right after the deadline.

thanks,
harish