Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 165809

Summary: allow a repository to be put into offline mode
Product: z_Archived Reporter: Mik Kersten <mik.kersten>
Component: MylynAssignee: Steffen Pingel <steffen.pingel>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P1 CC: robert.elves, wmitsuda
Version: unspecified   
Target Milestone: 2.0   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
add offline mode
none
mylar/context/zip
none
overlay icon (org.eclipse.mylyn.tasks.ui/icons/eview16/overlay-offline.gif)
none
do not report status when offline
none
mylyn/context/zip
none
updated patch that persists offline setting when changed none

Description Mik Kersten CLA 2006-11-24 13:40:35 EST
Sometimes repositories are inaccessible and synchronization should not be attempted.
Comment 1 Eugene Kuleshov CLA 2006-11-24 13:45:18 EST
He he. I thought you didn't want that feature. :-)
Comment 2 Mik Kersten CLA 2006-11-24 14:30:59 EST
I don't want the whole UI to go into an offline mode when casually moving from a connected to a disconnected state, because it puts a manual mode switch burden on the user.  But I'm OK with a single repository to be put in offline mode.  It opens up potential for confusion if you forget to re-enable it, but is needed for your use case and others, e.g. if someone goes on a 2 week vacation they may not always want to be synching to their work repository for that time.
Comment 3 Eugene Kuleshov CLA 2006-11-24 14:54:23 EST
I know. But if you'll do that, then it makes sense to allow to specify how often each repository should be synchronized too... :-)
Comment 4 Mik Kersten CLA 2007-04-10 01:28:53 EDT
*** Bug 181386 has been marked as a duplicate of this bug. ***
Comment 5 Eugene Kuleshov CLA 2007-05-16 15:24:06 EDT
BTW, I wonder if background sync should be running on queries/categories that don't match currently selected task working sets...
Comment 6 Mik Kersten CLA 2007-05-16 18:09:06 EDT
I think that they should be.  So that when you quickly switch working sets to see if anything new came in you have accurate incoming information, modulo the delay from the synch interval.  
Comment 7 Eugene Kuleshov CLA 2007-05-16 19:18:56 EDT
Maybe, but on the other hand, synchronizing those "uninteresting" tasks takes time, and they can be only made interesting one day a week, so may not worth to synch them every 10 or 20 minutes like tasks that are "interesting".
Comment 8 Mik Kersten CLA 2007-05-16 21:35:00 EDT
We only synchronize changed tasks.  So the only cost should be running the query for changed tasks.  Then there is additional overhead if a task changes multiple times in the week, since it will be synchronized during each change, but that should be small.  Unless there is concrete evidence that our current synchronization policy is a problem I don't think we should offload any work from the network at the expense of the user not having the information there instantly when they need it.
Comment 9 Steffen Pingel CLA 2007-05-16 21:51:44 EDT
The load on repositories might still be significant though (bug 187323). In fact for JIRA it is currently severely high since we download all tasks that have changed since the last synchronization.
Comment 10 Mik Kersten CLA 2007-05-17 15:05:11 EDT
Yup, connector implementation can definitely trigger traffic problems (e.g. always downloading task data).  But unless there is indication that those can't be solved on the connector end I think we should stick with our current lazy synchronization policy.
Comment 11 Steffen Pingel CLA 2007-06-05 20:53:04 EDT
Does this task require any API changes that we need to get done before Friday?
Comment 12 Mik Kersten CLA 2007-06-05 22:21:57 EDT
Seems like it can be done without API changes.
Comment 13 Mik Kersten CLA 2007-06-20 00:57:19 EDT
Steffen: I can't get to us until I'm done with fixing externalizers, so if you're willing to take a stab at it that would be great.  I think that all that needs to happen is to store a boolean isOffline() on TaskRepository and then exclude it from any synch.  In the Task Repositories view its icon should just become disabled or overlayed with something weird (I'll fix later) and then we need an action for toggline the online/offline state.
Comment 14 Steffen Pingel CLA 2007-06-20 01:14:48 EDT
I'll look into it after I have resolved bug 193430.
Comment 15 Steffen Pingel CLA 2007-06-20 04:08:50 EDT
Created attachment 71846 [details]
add offline mode

Patch does the following:

 * Adds an item to the repository context menu to toggle offline mode
 * Decorates the repository icon with a grey globe when offline
 * Skips repository in ScheduledSynchronizationJob when offline
Comment 16 Steffen Pingel CLA 2007-06-20 04:08:52 EDT
Created attachment 71847 [details]
mylar/context/zip
Comment 17 Steffen Pingel CLA 2007-06-20 04:09:44 EDT
Created attachment 71848 [details]
overlay icon (org.eclipse.mylyn.tasks.ui/icons/eview16/overlay-offline.gif)
Comment 18 Mik Kersten CLA 2007-06-20 11:04:17 EDT
Patch applied and looking good.  Great stuff Steffen.

Rob: we should verify that tasks that are opened from a repo that's offline don't get the warning icon...
Comment 19 Steffen Pingel CLA 2007-06-20 18:33:48 EDT
Created attachment 71965 [details]
do not report status when offline

Follow up patch that does not set show the warning icon when repository is in offline mode and task is synchronized in background (when the editor is opened).

Please review and apply.

Another thing I noticed is that the repository list is not saved when the offline status is toggled resulting in lost state if Eclipse crashes.
Comment 20 Steffen Pingel CLA 2007-06-20 18:33:51 EDT
Created attachment 71966 [details]
mylyn/context/zip
Comment 21 Mik Kersten CLA 2007-06-20 18:50:01 EDT
Rob: please review and apply
Comment 22 Steffen Pingel CLA 2007-06-20 18:53:53 EDT
Created attachment 71969 [details]
updated patch that persists offline setting when changed
Comment 23 Robert Elves CLA 2007-06-20 20:03:39 EDT
Patch applied.
Comment 24 Steffen Pingel CLA 2007-06-20 20:11:21 EDT
Thanks. Mik, the 2.0 plan needs an update now :).
Comment 25 Mik Kersten CLA 2007-06-21 04:16:34 EDT
Done, with pleasure :)