Community
Participate
Working Groups
As per requirements stated here: http://wiki.eclipse.org/index.php/ECF_Application_Refactoring add persistence support to the RosterView class in org.eclipse.ecf.ui plugin, org.eclipse.ecf.ui.views.RosterView class.
*** Bug 166668 has been marked as a duplicate of this bug. ***
I will use the mememto pattern which states that : "Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later". The states that could be restored are in first view: - windows positionn/size - perspective used - ... which other state is to be restored ?
Hi Pierre (In reply to comment #2) > I will use the mememto pattern which states that : "Without violating > encapsulation, capture and externalize an object's internal state so that the > object can be restored to this state later". > > The states that could be restored are in first view: > - windows positionn/size > - perspective used > - ... which other state is to be restored ? > The main thing is the roster contents (accounts, groups, buddies) for rosters that are not connected. The model here is Google Talk, which shows the current buddy list even if not connected. Obviously updates to buddy list can't be made unless connected, and we should have some way of visually indicating for each account whether it is connected (as ECF supports multiple accounts in a single list, while Google Talk only supports one account). See also description 2nd paragraph under Requirements and Design ideas here: http://wiki.eclipse.org/index.php/ECF_Application_Refactoring
(In reply to comment #3) > The main thing is the roster contents (accounts, groups, buddies) for rosters > that are not connected. The model here is Google Talk, which shows the current > buddy list even if not connected. I'm not sure I agree with this. The only client that I've ever seen support this as far as I remember since using IM clients in 1999 would be ICQ. And...that's a maybe, because it's been so long ago now that I could be wrong since I use Gaim now. Anyway, is this a new feature of Google Talk or something? Because I just tried it and it didn't seem to work, or, of course, I could be doing it incorrectly. I signed in, then I went offline, then my whole buddy list was hidden and the username/password text fields came back up to prompt me. According to the Windows executable, I'm on version 1.0.0.98. Of course, just because some clients don't support this doesn't necessarily mean we support it too. So the question is, why don't they? I think the answer is security. Your list of contacts is like your address book. If someone came over do you really want them to be able to fire up AIM while you turned your back away, sneaking a peek at who's on your list without signing in with the right credentials? The worst part is if they find out you deleted them from your list. ;P If we're implementing this I'm going to request a feature for removing the contacts associated with a given account. I don't really want or need to have a list of my friends' contacts on my ViewPart if they happen to sign on while using Eclipse on my notebook.
Okay, I think I see where the "still see contacts when offline" is coming from. I think Eugene was referring to the user interface that's provided when browsing GMail through a browser. In this context, you are still actually logged in to a given service, but you're just not online. I would be willing to live with this, I guess.
Created attachment 57060 [details] persistence as memento example This patch is a sample for showing and proposing how to implement persistence in RosterView - by the content provider. What is to be decided yet is which should be persisted. The mechanism to persist is interfaced in ECLIPSE and I have choosen one of these: IpersistableElement, added to RosterViewContentProvider.
Thanks for the example code Pierre. Do you intend that this would be applied to the codebase, or used only as an example? On first observation it doesn't look like this snippet is quite complete. But let me know and we can discuss further what can be persisted. Thanks. (In reply to comment #6) > Created an attachment (id=57060) > persistence as memento example > This patch is a sample for showing and proposing how to implement persistence in > RosterView - by the content provider. What is to be decided yet is which should > be persisted. The mechanism to persist is interfaced in ECLIPSE and I have > choosen one of these: IpersistableElement, added to RosterViewContentProvider.
(In reply to comment #7) Scott, This patch is just a proposal to be validated, but it's based on the rcp framework method used to persist states in the ide. The IPersistableElement interface allows to persist all sorts of elements and particularly those that conform to a tree pattern.
I think we should modify this bug to be to 'add persistence to [new] MultiRosterView). Title changed. If any objections, please state. (In reply to comment #8) > (In reply to comment #7) > Scott, > > This patch is just a proposal to be validated, but it's based on the rcp > framework method used to persist states in the ide. The IPersistableElement > interface allows to persist all sorts of elements and particularly those that > conform to a tree pattern. >
(In reply to comment #4) > I'm not sure I agree with this. The only client that I've ever seen support this > as far as I remember since using IM clients in 1999 would be ICQ. And...that's a > maybe, because it's been so long ago now that I could be wrong since I use Gaim > now. All clients I've used do keep buddy list when you are offline (Skype, ICQ, Miranda, Trillian). I think generally it is a better approach then wiping out Roster on disconnect from the network. For an add-on value, persistent view could be used as an address book (especially allow to access that info from other plugins, i.e. to support completion, etc). It would be interesting to have special presentation model that would allow to link different user accounts (i.e. same user on gtalk and on skype) and even link those accounts with other services such as Bugzilla, JIRA, CVS, SVN and emails. For such purpose it would make sense to abstract user list shown in Roster view from the concrete protocols and instead expose protocol services trough some actions.
Changing version to 1.0.1 and target milestone to Final. Unfortunately I don't think we can get to this before Europa.
Setting target milestone to 1.1.0.
(In reply to comment #12) > Setting target milestone to 1.1.0. > We need to do is establish what storage mechanism is going to be used to implement this. My inclination is to use the IPreferencesService and create a new scope for preferences (ECF UI). Any comments? Of course none of this is secure, so it will have to be insecure until we have the JAAS/Equinox secure storage (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1549).
Regrettably won't be able to get to this for 1.1 given other ongoing work on MultiRosterView. Changing target milestone.
Changing tm.
changing target milestone
Removed myself from assignee and reduced importance.
Seems like this is not going to happen. Resolving as wontfix. BTW, note that ECF does have a secure storage system now...via secure preferences and the org.eclipse.ecf.storage API...so if someone would like to take this up in the future please reopen.
