Bugzilla – Full Text Bug Listing
| Summary: | [UI] Enhance hyperlinking support | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Chris Aniszczyk <caniszczyk> |
| Component: | ecf.ui | Assignee: | ecf.core-inbox <ecf.core-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | mayworm, mik.kersten, slewis |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | 2.1.0 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Chris Aniszczyk
btw, what are people's thoughts on this issue? ok, I looked at our current hyperlink story... it's very tied to strict URIs (ie., xmpp://user@domain.com.... people hardly ever interact this way. We need to be better at guessing names or ids, for example, if we're looking at a source editor with an address like (user@domain.com), we should do a best guess approach at trying to find an active account. The question now is, do we enhance our existing hyperlink detector stuff, or do we just create a new detector? What are your thoughts Scott here as I believe you did the first pass of hyperlink stuff. I'll try to hack something up in presence.ui for a PresenceHyperlinkDetector, however, I'm getting sleepy! (In reply to comment #2) > ok, I looked at our current hyperlink story... it's very tied to strict URIs > (ie., xmpp://user@domain.com.... people hardly ever interact this way. > > We need to be better at guessing names or ids, for example, if we're looking at > a source editor with an address like (user@domain.com), we should do a best > guess approach at trying to find an active account. > > The question now is, do we enhance our existing hyperlink detector stuff, or do > we just create a new detector? > > What are your thoughts Scott here as I believe you did the first pass of > hyperlink stuff. > > I'll try to hack something up in presence.ui for a PresenceHyperlinkDetector, > however, I'm getting sleepy! > It's going to be tricky introducing a hyperlink detector for user@domain.com...because there's no indication of whether that's email, xmpp, msn, yahoo, google, etc., etc. Somehow or other (ask user at link presentation time, set prefs/defaults for accounts, use some other key combo, change matching based upon what connections currently exist, etc) we have to have some more info. The hyperlink detector extension point seems to support the notion of several/number of hyperlink detectors matching a given string, but I don't know what UI is presented when this is the case (i.e. how does the user choose one if there are several matches). I simply haven't had occasion to try it yet. If there were some conventions around (e.g.) @author Chris Aniszczyk <caniszczyk@gmail.com> And we knew that (e.g.) caniszczyk@gmail.com also had an associated google talk account (or caniszczyk@eclipse.org had an xmpp account, etc) then we could use this for detection also. We do need to worry a little bit about responsiveness for hyperlink detection (i.e. we can't do any network operations within the detector code) as otherwise the link might not show up fast enough. Anyway, there are a lot of potential solutions here, I think we just need to explore the space a little more. I talked to Chris about this last night but figured I'd log it here. It should be noted that a user ID can be associated with multiple instant messaging accounts. So some kind of a dialog for selection which account to talk to will be required. So here is another thought... would we allow for something like aliases? For example, I use <zx@us.ibm.com> on pretty much every bugzilla. However, if I was on gtalk, would it be possbily for someone to setup an alias for my account as "zx@us.ibm.com" and message me using gtalk? (In reply to comment #5) > So here is another thought... would we allow for something like aliases? > > For example, I use <zx@us.ibm.com> on pretty much every bugzilla. However, if I > was on gtalk, would it be possbily for someone to setup an alias for my account > as "zx@us.ibm.com" and message me using gtalk? > Aliases could also be done...based upon associations as per comment #4. We can create a unique identifier for a user and associated other IDs/Accounts,credentials, etc with that user. IMHO the 'tough' part about this is connecting with the forthcoming Equinox + JAAS authentication framework for login/user authentication (ECF IDs extend java.security.Principal, so the connection is already there for all intents and purposes), and having some relatively secure local storage for the association information (since there is no means to store this info on servers). I would like to see ECF IDs and aliases created upon Equinox login (via JAAS) and associated with the JAAS Subject. And persisted to a user-controlled secure local storage. This will probably involve adding extension points to Equinox JAAS (to allow ECF plugins to create principles during login process), and using whatever secure user storage facilities Equinox provides in the future. Note that the JAAS Equinox contribution has just been approved for parallel IP/Equinox incubator checkin https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1549 (In reply to comment #7) > Note that the JAAS Equinox contribution has just been approved for parallel > IP/Equinox incubator checkin > > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1549 > Another reference...a relevant posting from Eugene: http://jroller.com/page/eu?entry=always_one_click_away A relevant passage: To fix that, we'll need some support on the ECF side, i.e. have some kind of mapping between issue trackers, project teams and individual entries from the ECF's contact list. If ECF would pass its contact instance to the hyperlink detector context, so we could anchor an adapter factory to their type and use external metadata to establish the link to the issue tracker (i.e. using Maven POM or info from Eclipse Corona)... We already have a number of entities (e.g. RosterEntry, Roster, RosterGroup) that implement IAdaptable, so it should be possible to define adapters to them using org.eclipse.core.runtime.adapters. Once one has the RosterEntry...one can/could look into the presence properties for that entry (i.e. IRosterEntry.getPresence().getProperties()) which can/could contain mapping info to email, issue trackers, for that contact) and use info to decide what hyperlink detection to use. This sounds like a very neat idea. In Mylyn we already have a similar notion of having structured references to people via the content assist that we add to the bug editor and I've been tempted to add this kind of hyperlinking and content assist to the Java editor, mainly for @author tags which I frequently fill out when contributors forget to. Here is the 'trick' that we use on Mylyn for making links like "bug 123" know which Bugzilla repository to go resolve the hyperlink reference too. It could be relevant to easing the mapping from email to IM/URI identity. 1) Have the user associate the place where the hyperlinks can occur with the repository that can resolve the reference to the hyperlink. Since Mylyn needs to resolve a mapping from IResources (e.g. history view entry, .java editor) to tasks in a TaskRepository, we have the user configure the association on a project page. Similarly ECF could associate projects with an IM/email identity repository/service. 2) Use that mapping to look up the structured element that the link refers to via obvious matching rules. For Mylyn that meand matching JDB-123 to a JIRA key by looking up (and caching) all keys to JIRA issues on the server. For ECF it could mean doing something like the full email and then falling back to the first segment of the email, etc. I'll be very curious to watch your progress on this because at some point I would love to see unified support for referring to people across task repositories and IM clients. Let's work on this for ECF 1.0.3 target milestone to 2.1 and change to enhancement Resolving as wontfix due to limited resources. If contributors or committer resources become available for additional work in this area then please reopen. |