Community
Participate
Working Groups
allow to customize names in the Roster view
I take it that you want to rename your contacts directly via right-click -> Rename?
Yes. But that should be local rename and I don't really want to send anything back to server. Actually, it is complete mystery to me where ECF gets Roster structure from. I'd say that IM client should allow to organize or regroup contacts freely. That is particularly important if we'll add additional functionality and integrate Roster view with other tools.
(In reply to comment #2) > Yes. But that should be local rename and I don't really want to send anything > back to server. > > Actually, it is complete mystery to me where ECF gets Roster structure from. The short answer is that it gets it from the provider implementing the presence API (implementations...XMPP, Yahoo, Skype, MSN, etc). Part of the presence API is the IRosterManager: http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/presence/roster/IRosterManager.html The 'getRoster()' method exposes access to an IRoster instance. This and the IRosterGroup/IRosterEntrys define the roster 'model'. The provider implementations (XMPP) implement this model and the UI in org.eclipse.ecf.presence.ui depend only upon the definition of the model. The IRosterListener(s), if any, are asynchronously notified of changes to the roster contents. It's up to the provider implementation to determine where this structure is actually stored (i.e. on server or clients). The existing provider implementations...like XMPP...store this information on the server. We haven't yet finished implementing a presence API provider that stores this info on peers (although Pierre has been working on a JXTA provider that would do that). > I'd say that IM client should allow to organize or regroup contacts freely. > That is particularly important if we'll add additional functionality and > integrate Roster view with other tools. OK. Can you please describe a use case for regrouping contacts? Specifically, is the expectation that this reorganization would be tied to a particular UI/workbench? or is the expectation that other clients (e.g. GAIM, Google Talk, Skype, etc) would reflect this regrouping as well (i.e. from server changes)? The reason I ask is that because in some cases (because of the way accounts/roster info is managed by the services/servers), it may be difficult to regroup contacts in ways other than just for presentation within the ECF clients (although this is relatively easy to do).
(In reply to comment #3) > OK. Can you please describe a use case for regrouping contacts? Easily. I have project members that are using different IM systems. It does make sense to group them by project, so I would see them all together and won't have to hunt each of them within several dozen of other contacts. > Specifically, > is the expectation that this reorganization would be tied to a particular > UI/workbench? or is the expectation that other clients (e.g. GAIM, Google Talk, > Skype, etc) would reflect this regrouping as well (i.e. from server changes)? I don't think it should be server-side grouping. But since you mentioned it, it does make sense to allow to apply different "working sets" to the roster view. So, it will be possible to filter out and regroup Roster view for the current activities. > The reason I ask is that because in some cases (because of the way > accounts/roster info is managed by the services/servers), it may be difficult to > regroup contacts in ways other than just for presentation within the ECF clients > (although this is relatively easy to do). I think that client-side presentation will be sufficient. Potentially it could be a pluggable presentation that may get info about project members from external metadata (i.e. Maven or Jazz).
(In reply to comment #4) > (In reply to comment #3) > > OK. Can you please describe a use case for regrouping contacts? > > Easily. I have project members that are using different IM systems. It does > make sense to group them by project, so I would see them all together and won't > have to hunt each of them within several dozen of other contacts. OK. But it strikes me that perhaps this would be better approached as a modified/extended project viewer (i.e. to have team members/rosters presented within projects along with other resources) rather than adding knowledge of projects and project resource navigation (and their dependencies) to a contacts view? Or linking them together (ala package explorer and Outline views)? I'm just exploring alternatives. > > > Specifically, > > is the expectation that this reorganization would be tied to a particular > > UI/workbench? or is the expectation that other clients (e.g. GAIM, Google Talk, > > Skype, etc) would reflect this regrouping as well (i.e. from server changes)? > > I don't think it should be server-side grouping. But since you mentioned it, it > does make sense to allow to apply different "working sets" to the roster view. > So, it will be possible to filter out and regroup Roster view for the current > activities. Couldn't this also leverage the existing support for working sets in the navigator, package explorer or filters in the project explorer...or is this not what you are thinking? > > > The reason I ask is that because in some cases (because of the way > > accounts/roster info is managed by the services/servers), it may be difficult to > > regroup contacts in ways other than just for presentation within the ECF clients > > (although this is relatively easy to do). > > I think that client-side presentation will be sufficient. Potentially it could > be a pluggable presentation that may get info about project members from > external metadata (i.e. Maven or Jazz).
(In reply to comment #5) > But it strikes me that perhaps this would be better approached as a > modified/extended project viewer (i.e. to have team members/rosters presented > within projects along with other resources) rather than adding knowledge of > projects and project resource navigation (and their dependencies) to a contacts > view? Project Explorer/Navigator is already has way too much data and it will be simply hard to find users in there (even with Mylar). So, it seems like separate view is a better fit. it would also help to use drag and drop from Package Explorer to some user. > Couldn't this also leverage the existing support for working sets in the > navigator, package explorer or filters in the project explorer...or is this not > what you are thinking? I was thinking of specialized working sets for the Roster view. Note that we are planning to add working set support to Mylar's Task List view (so you can add categories/queries to working sets and choose which working sets should be shown at the given time).
(In reply to comment #2) > Yes. But that should be local rename and I don't really want to send anything > back to server. Could you explain why you'd want a local rename that is not pushed up to the servers? If a user renames a contact and then logs onto his account from another computer, the changes will not be reflected. Isn't this a little counterintuitive?
(In reply to comment #7) > Could you explain why you'd want a local rename that is not pushed up to the > servers? If a user renames a contact and then logs onto his account from another > computer, the changes will not be reflected. Isn't this a little > counterintuitive? It depends. I assume that server-side renames are harder to implement and there is no guarantee that all providers can handle them. Besides, user may want to see different names between different computers and/or external IM instances (i.e. real names vs. nicks, sometimes that can be driven by the screen real estate). Also, to solve configuration issues you may allow to export/import roster list. BTW, I am still very confused that users disappear when I want to disconnect from the server.
(In reply to comment #8) > BTW, I am still very confused that users disappear when I want to disconnect > from the server. Hi Eugene, can we continue this persistence discussion on bug 166670 and leave the renaming issue on this one? You can take a look at the 4th and 5th comment on that bug as to my views on this.
It seems to me (especially given comment #9 and comment #10) that this bug dependent upon roster client-side persistence, so I'm adding bug 166670 as dependency. Also setting target milestone.
Resolving as wontfix. If resources become available to work on this enhancement, please reopen.
