13710 - [FEATURE] Compact folder for POP

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P1)

Description

[scottputterman]

Need to implement Compact folder for POP.

Comment 1

[sol]

Jeff - any chance we'll get this in Beta 1?

Comment 2

[jefft]

I'll try my best.

Comment 3

[lchiang]

(target milestone is M11 or M12 - add to mail beta tracking bug)

Comment 4

[jefft]

The chance to get this in beta 1 is slim at the moment. We don't have the
mailbox protocol support for comporessing the folder. The code hasn't been
ported over. There will be too much work to get it work today.

Comment 5

[jefft]

It's way too much work for less than a day I think. What it needs to be done
are:

o First make sure that the database is dirty, there are messages being deleted,
expunged bytes not equals to zero.
o Create a temp folder & a temp database
o Open the original folder & database
o Read through the database and start copying messages which haven't been
deleted to the temp folder. Make sure to parse the message lines and add the
message headers to the database.
o When done with copying the messages. Close the temp folder and database.
o Rename the old folder and database to something else and new temp folder and
database to be the original folder and database.
o Refresh/rebuild the RDF graph since all keys/offsets are different.
o This should be implemented as an asynchronous operation. We don't want to
tieing up user interface especially when compressing all folders.

Comment 6

[Phil Peterson]

M15, clearing dependency on 11091

Comment 7

[Matthew Tuck [:CodeMachine]]

Phil, you forgot the dependency removal.  Making it so ...

Comment 8

[jefft]

I think compacting pop3 mail folder is pretty important. There is no way for
users to reclaim the disk space without extensively knowing what
x-mozilla-status flags means. We might want to consider doing this earlier than
later.

Comment 9

[leger]

Putting on [PDT-] radar...sorry...

Comment 10

[jefft]

Removing [DOGFOOD] tag.

Comment 11

[Jim Roskind]

Removing PDT annotation now that dogfood nomination has been removed

Comment 12

[jefft]

This is a big task especially do it asynchronously. Currently, we don't have the 
guts supproted in mailbox url, service and protocol. We also need to do handle 
one or more or all folders compression.

Comment 13

[Phil Peterson]

Jeff, let's find simplifying assumptions here. It wouldn't be the end of the
world if we did this synchronously.

Comment 14

[jefft]

No, it's not the end of the world. What I meant was ETA on 03/30/00 seems not 
feasible to do it asynchronously.

Comment 15

[jefft]

Fix checked in. There are still have some UI synchronous problem such as 
reselecting the previous selected message. Since, compacting is asynchronous now 
reselecting the previous selected message requires a lot of work we should 
address it in another bug.

Comment 16

[David :Bienvenu]

can you just do it when the url is finished, by registering a url listener?

Comment 17

[jefft]

I don't think so. I can implement url listener interface for compact folder 
state but won't help much it will get call each time we do a CopyMessage(). 
OnStopRequest() essentially does the same thing. We need to tell the js when 
compact is done and the new key gets communicate to the js. A side note: we also 
need to update the compact status periodically.

Comment 18

[scottputterman]

why don't we do it the same way we do when we finish a delete or move?  We can 
send off a folder listener event using OnFolderEvent() and then the js can catch 
it.  If we need to send in more information we can either add a new function to 
the folder listener or we can modify OnFolderEvent to take an extra nsISupports 
parameter.

Comment 19

[jefft]

Yes, that's the way we should go. I would like to have another bug address this.

Comment 20

[jefft]

*** Bug 34047 has been marked as a duplicate of this bug. ***

Comment 21

[Karen Huang]

Verified on WinNT 05-12-21-M16 commercial build.
Marking as verified.

>reselecting the previous selected message requires a lot of work we should 
>address it in another bug.

Jeff, what's above problem? Any bug already addressed above problem?