Re: [Evolution-hackers] compression for folders?



I do see your point.  I still think (as I said in the comments I added
to the bug report) that compression and archival are separate
functionality, to be implemented independently, but I do understand how
archived data makes it much less a pain to implement properly than
active folders.

Just to be clear, if you were to have your preferences, would you
advocate archival is always read only, or archival can be modified like
standard folders?  Aka lets say I go back in archives and notice
something was filed in the wrong folder, or I never replied to an
email.  Would the reply flag be set on that email if I do reply, and
would I be allowed to move an email message from archival to an active
folder or even from one archival folder to another?  Personally, I'd
have no issues if there was some extra overhead in doing this, but I
would definately want this functionality.

On Thu, 2004-05-06 at 11:08, Jeffrey Stedfast wrote:
> On Tue, 2004-05-04 at 11:51 -0500, todd fries net wrote: 
> > I'm not quite sure what the difference between archival and transparent
> > compression would be.
> 
> the obvious answer is that with archived folders, the folders can be
> considered to be "read-only" which means compression won't really get
> in the way (performance wise) since the folders can be assumed to be
> read only "once in a while".
> 
> whereas, if you wanted to enable compression for your "in-use" (for
> lack of a better term?) folders, then it would be a significant enough
> problem to make it a pita because they are constantly being modified
> (appended to, expunged, etc).
> 
> Jeff
> 
> > I get the impression archival would be, well, not very useful if I
> > wanted to see all emails from my wife since I've known her, for example.
> > Would vfolders work on archives?  If so, then what is the difference
> > between transparent compression and non transparent compression?
> > 
> > BTW, you guys misread my statement.  I have 3gb of mbox files that are
> > compressed already with 'bzip2 -9' ..
> > 
> > In general, I never throw away email, because I have so much spam that I
> > can't trust the auto filters to throw it away, and on more than one
> > occasion important documents have been retrieved from the spam filter
> > box, case in point the recent tax season saw the pdf email from my
> > accountant show up in the spambox.
> > 
> > Anyway, I need not justify to you guys why I have so much mail, only
> > impress upon you that I do have so much mail that I wish to utilize
> > evolution to access.
> > 
> > I'm going to test out a port of 1.5 to OpenBSD and from there perhaps
> > migrate to cvs head, from which I can consider developing transparent
> > compression techniques.
> > 
> > Looks like I'll be searching for the bug related to this ?? .. hopefully
> > it isn't too small of a needle buried in too big of a proverbial
> > haystack.
> > 
> > On Sun, 2004-05-02 at 22:17, Not Zed wrote:
> > > On Sun, 2004-05-02 at 12:53 +0300, Enver ALTIN wrote: 
> > > > On Fri, 2004-04-30 at 11:17 -0500, Todd T. Fries wrote:
> > > > > I am now using evolution 1.2 on OpenBSD for whatever that is worth, and
> > > > > have about 3gb of bz2 compressed files to move into evolution folders.
> > > > 
> > > > Isn't 1.2 a bit outdated to talk about?
> > > > 
> > > > > Are there any mechanisms proposed or existing to compress email folders?
> > > > 
> > > > Not yet, and the very common answer for similar/related questions in the
> > > > past was: "No, and it's not planned anytime soon". Transparent
> > > > compression will probably break vfolder and searching facilities causing
> > > > a lot more usability and long term maintenance problems. I doubt Gerardo
> > > > will like the idea :)
> > > Well transparent compression would be ... transparent, so everything
> > > would still work if it was done properly.
> > > 
> > > My take on it is that it just isn't worth it on its own - hard drives
> > > are SO cheap these days.
> > > 
> > > If you've got 3GB of email lying around it sounds like its actually
> > > archival you're after ... i'd certainly support some sort of
> > > development of compressed archive mode folder stuff.
> > > 
> > > i.e. not just a general folder compression option, but a special
> > > backend for archival and/or hsm storage.
> > > 
> > > 
> > > 
> > > Michael Zucchi
> > > <notzed ximian com>
> > > 
> > > Ximian Evolution and
> > > Free Software Developer
> > > 
> > > 
> > > Novell, Inc.
> > -- 
> > Todd Fries .. todd fries net
> > 
> >  _____________________________________________
> > |                                             \  1.636.410.0632 (voice)
> > | Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
> > | http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
> > | "..in support of free software solutions."  \  1.700.227.9094 (IAXTEL)
> > |                                             \          250797 (FWD)
> >  \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
> >                                                  
> >               37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
> >                         http://todd.fries.net/pgp.txt
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > evolution-hackers maillist  -  evolution-hackers lists ximian com
> > http://lists.ximian.com/mailman/listinfo/evolution-hackers
> > 
> 
-- 
Todd Fries .. todd fries net

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \  1.700.227.9094 (IAXTEL)
|                                             \          250797 (FWD)
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt








[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]