Closed Bug 15865 Opened 26 years ago Closed 24 years ago

[FEATURE] Offline IMAP

Categories

(SeaMonkey :: MailNews: Backend, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Backend
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: phil, Assigned: Bienvenu)

References

Details

(Whiteboard: [nsbeta1+])

To my surprise, we don't have a feature bug for offline use. I know we've talked generally about it, and it wouldn't be done in time for B1. I'm entering this bug as a placeholder for us to make a decision in the B1-B2 timeframe. cc hangas, sspitzer
Depends on: 8039
Depends on 8039 - but why is this whole bug assigned to me? I'm only doing offline IMAP. I think we should have separate bugs for each offline feature.
QA Contact: lchiang → laurel
Summary: [FEATURE] Offline use of mail/news → [FEATURE] Offline IMAP
Ok, changed scope to offline IMAP and entered 15870 for news.
Blocks: 10791
Status: NEW → ASSIGNED
Target Milestone: M20
*** Bug 24045 has been marked as a duplicate of this bug. ***
moving to P5 - not going to happen, as I understand the schedule.
Priority: P3 → P5
moving to future.
Target Milestone: M20 → Future
Especially now that the fuss over ns6 seems to be receding, I'd really like to see some progress in this area. As well as being the highest (equal) voted IMAP bug, I think this is probably the biggest mail feature missing from 4.7 (Windows) that regular users would notice. The requirement to be online to even *read* IMAP mail makes use over a dialup line quite impractical. I've said it before and I'll say it again: ns4.7 for Windows has the best offline IMAP support I've seen *anywhere*. Several times I've been tempted to install Wine just so that I can run the Windows version of 4.7 under Linux, but I like to "eat the dogfood" and help out with Mozilla where I can. Perhaps it would be a good idea to separate this bug into small subproblems so that incremental progress can be made in this area. I don't know the design details of how this will be implemented, but these are just starters that others such as bienvenu can refine. 1) Use of a separate persistent (i.e. disk based) cache for IMAP messages, so messages can be retained between sessions. This should be separate from the existing disk cache, because it's quite reasonable to want to cache all IMAP mail (whereas the existing disk cache is rightly capped), and we wouldn't want regular web pages to push messages out of the cache. When offline, this cache should probably be considered read-only. 2) Simple Synchronization 2a) The ability to flag folders for synchronization. 2b) The ability to perform synchronization, which ensures that the disk cache fully mirrors the server contents of the selected folders. 3) Full offline support 3a) Implementation of operation recording when modifying imap folders offline 3b) Playback of recorded operations when going online Hopefully we can get a little discussion and file the refined subproblems as bugs that this bug depends on. Can any of the offline imap code from 4.7 be salvaged?
darn, I had a bugzilla conflict with your last update, Len, so I lost all of my answers to your questions. But we are definitely thinking about doing this, and I have some of the design written. We can't use much of the 4.x code for various reasons, though the design will be similar.
Do you really want lots of smaller bugs to track the "feature work" which aren't necessarily bugs? Would this one tracking bug suffice?
It's not really "lots" and makes it easier to record the incremental progress towards having full disconnected mode support. (we dont' have just one "mozilla isn't finished" bug :-))
If you're asking me, no, I definitely don't want a lot of small bugs on this. I'm happy with one FEATURE tracking bug for now.
recording the incremental progress in this one bug would be sufficient, I think.
I thought that a division along the lines of the three steps that I proposed would mark sufficient advances in IMAP usability that they would warrant treating separately, but I guess if they're all going to be assigned to David anyway they may as well all go here :-). It sounds like David has made some progress in this area, I'd be really interested in seeing a few more details on the status -- there was nothing of note recorded in this bug since it was opened last year.
Yes, I would be doing all the work, but you're right that those are the logical steps to do an implementation. There's been no progress on this because we've known for many months that offline imap wasn't going to make it into 6.0, and we were pretty busy getting the stuff that is in 6.0 to work.
David, if it's at all possible that some other Mozilla contributor would be able to implement parts of this feature before you get around to it, then filing smaller bugs (describing clearly what needs to be done, and what parts of the code to start looking at) would be useful.
adding mail3 keyword
Keywords: mail3
changing component.
Component: Mail Back End → Offline
changing priority, marking nsbeta1+ and moving to mozilla0.9 milestone.
Keywords: nsbeta1
Priority: P5 → P1
Whiteboard: [nsbeta1+]
Target Milestone: Future → mozilla0.9
moving to mozilla0.8 milestone.
Target Milestone: mozilla0.9 → mozilla0.8
moving to mozilla0.9 because this is a work in progress and will be finished up in the 0.9 time period.
Target Milestone: mozilla0.8 → mozilla0.9
QA Contact: laurel → gchan
David, would it be possible to post a status update on this feature? I've seen in the cvs logs and progress reports that there's been a lot of activity linked against this feature, but not a semi-official "these bits are ready to bang on" :-) Is it safe to start playing with some of this stuff? What should be working currently? (Should we file bugs for any problems found in "working" areas?) What should we stay away from?
good question. The backend is mostly done, but the front end is non-existent, other than the rather sad stuff I've managed to hook up myself, like the "select this folder for download" checkbox in the imap folder properties dialog. The two offline menu items File | Work Offline and File | Synchronize are supposed to pop up a dialog saying what to synchronize - for my own testing purposes, I just assume everything is to be synchronized/downloaded. The playback of offline imap operations is not tested very much. I got it working, but haven't tested it extensively. So this is the area that is not safe, because you could lose your offline changes, or worse, have destructive things happen when you playback your offline changes. But if you'd like to try it, go for it :-) One really useful thing would be to be gathering an IMAP protocol log while doing this, because that makes it easier to diagnose problems. What does work fairly well is downloading messages for offline use and reading them offline, replying to them offline, etc... I guess we can start filing bugs on this - However, I'm reluctant to be ambushed by Laurel's initial barrage of bugs when she tries this feature, however.
(While I'm changing my email address I may as well add a comment). I haven't played with the synchronization bits yet, but have turned on the folder properties to select the folder for download. Currently the only way to have messages "persistently downloaded" (I take it this is what the italicized threadpane face indicates) is to explicitly select menu items from the offline menu -- messages should also be put into this state during normal online message viewing (well, any time a message is downloaded). Would it be possible to swap the faces used for "persistent" vs "non-persistent" messages for offline folders (i.e. use italics for those that have not yet been downloaded to the persistent store, and regular face for those that are)?
messages *are* downloaded for offline use when you read them, if the folder is configured for offline use, at least for me. If the messages are over a certain size, they won't be downloaded - the size is controlled by a pref that defaults to 50K: pref("mail.server.default.limit_offline_message_size", true); pref("mail.server.default.max_size", 50); The italics are temporary until we get an icon for messages that have been downloaded for offline use. But you can probably play with your own .css to get the behaviour you want (but don't ask me how).
Ahhh, the problem was that some prefs had appeared in my prefs.js that set the max_size to 0 (I hadn't changed them myself, so I assume it happened as the offline support was in development). I've removed them and set the limit message size pref to false. We'll see how things go.
moving to mozilla0.9.1 where we'll be able to finish this up once testing can begin with the FE.
Target Milestone: mozilla0.9 → mozilla0.9.1
marking fixed - we can open new bugs on problems found.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking this verified. Implementation in on all platforms in commercial trunk daily builds, testing begun and separate bugs being logged.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.