Re: [evolution-patches] Unified Attachment Bar Patch

[Not Zed <notzed ximian com>]

On Mon, 2005-07-11 at 15:33 +0530, Harish Krishnaswamy wrote:
> 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.

The whole patch is the rewrite.  Fixing a seriously broken patch is not
a 'rewrite'.

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

Errr, ok.

I can't say I agree with this, 2.3.x is a development release anyway,
what's the big rush to get a crappy broken patch in right now?