Closed Bug 15865 Opened 25 years ago Closed 23 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: 23 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.