Bugzilla – Full Text Bug Listing
| Summary: | [appint] Provide ability to export/import task context via ECF communications | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Jevgeni Holodkov <jevgeni.holodkov> |
| Component: | ecf.ui | Assignee: | Remy Suen <remy.suen> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | ebaron, harshana05, ksebasti, mik.kersten, mlists, mn, nboldt, phidias51, remy.suen, sebastian.schmidt2, slewis, steffen.pingel, vytautas |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Jevgeni Holodkov
Rob, assign this bug to me, please. I am not empowered enough to do this myself. I don't think notification windows is a good idea. Much less intrusive approach would be to show some icon in the status bar upon such "sharing" requests. So, user can choose to click on it at the convenient time, which can be hours since request is sent. Given that it is probably makes sense to accept and receive these context files and put them into some "inbox" area where they can be taken from. Maybe such "inbox" can be even shown in the Task List as a special folder. Then one don't even need an import wizard and can just drag it into a local folder or delete instantly after reviewing its content. Status icon is a good idea, but in order not to miss it, I suggest that the message in chat should also appear. One can be "You are about to receive the context, click flashing icon to get the context" or something similar to it. As to "inbox", I was considering this as well, but for me it looked pretty much the same as sending the context by a regular email. I need to find first if this is possible to create such inbox (logically, If I would be a framework, I wouldn't allow to receive any type of data without permission - the receiver side should anyway to accept the incoming data somehow) -1 to anything flashing. Jeveni: the simplest thing to do is to take the current approach of IM tools and just to make this show up as a special thing in the chat window that the user can click to import the context. I assume that ECF has some sort of UI for notifying when there is a chat message, and this is just another form of chat message. *** Bug 204053 has been marked as a duplicate of this bug. *** Adding my usecases to the list: I'd like to be able to send/receive tasks from other users working on a project. We don't have a task repository and are just using the local repository on our own machines. Basically this would involve, exporting the task(s) as XML and using the jabber protocol to send the tasks to another member of the jabber group. It would then allow the user to accept those tasks and they would be automatically added to their local repository. The process would work like this: Use Case I: Delegating a Task (1) User selects those tasks that they want to send to another user. (2) They right click in the Task List window on one of the selected tasks, and select a "Send To" pop-up menu item. (3) A dialog appears allowing them to select one of the other users currently logged on. (4) The selected tasks are exported as XML and sent as an attachment on an IM message to the user. (5) The remote user receives a pop-up indicating that they have incoming tasks. The incoming tasks appear in an "InBox" category (in addition to their original category). (6) The remote user can choose to accept the tasks, which then removes them from sender's task list. If the remote user rejects the tasks, then the tasks remain in the senders task list and are removed from the remote users task list. Use Case II: Consolidating Task Lists There's often the need for the efforts of multiple people to be coordinated. It would be useful if the local tasks associated with a given project could be consolidated into a single task list. (1) Each user of the team can indicate that a specific category is "shareable". Any task placed in the "shareable" folder can be seen by any other team member who wants to subscribe to it. (2) A subscribing user can create a folder, browse all peers for sharable folders, and select the appropriate ones to subscribe to. Those tasks and any updates are automatically synchronized. (3) The subscribing user can create a report that combines all of the tasks into a single report, or export the tasks into a single XML document. The user could select a transform to convert the document into different formats to suit their needs. The main formats I'm thinking of are HTML (for status reports) and GAN for GanttProject files. Jevgeni, any updates to this? I guess this bug is essentially dependent on bug 178883? (In reply to comment #8 and #9) > Jevgeni, any updates to this? > I guess this bug is essentially dependent on bug 178883? > The core functionality about exporting/importing is done. This task is only about the transport. This task now is with a low priority by two reasons. You still can drap&drop the task to the external IM client. The second is a limitation of ECF about the proxy, which makes impossible to connect to ECF, if the PC is behind the proxy. For me this issue is a blocker both in using and developing (In reply to comment #10) > The second is a > limitation of ECF about the proxy, which makes impossible to connect to ECF, if > the PC is behind the proxy. For me this issue is a blocker both in using and > developing When you say "connect to ECF", what do you mean exactly? Are you using the ECF client to connect to an xmpp account or something or another? (In reply to comment #11) > > When you say "connect to ECF", what do you mean exactly? Are you using the ECF > client to connect to an xmpp account or something or another? > Sorry, I've meant 'connect using ECF'. I wasn't able to connect to XMPP server (gtalk server) when behind the proxy. (In reply to comment #12) > > When you say "connect to ECF", what do you mean exactly? Are you using the ECF > > client to connect to an xmpp account or something or another? > > > Sorry, I've meant 'connect using ECF'. I wasn't able to connect to XMPP server > (gtalk server) when behind the proxy. Thanks for the clarification, Jevgeni. I'm going to CC Scott on this bug to get his comments. (In reply to comment #13) > > Thanks for the clarification, Jevgeni. I'm going to CC Scott on this bug to get > his comments. > I remember we have already been discussing this issue with Scott for a while. The hack solution for the development was to use local XMPP server, but there were no workaround for users. As to implementing the proxy handling in ECF - at that time there were more essential features to implement, so this issue, as I've understand, had a lower priority. (In reply to comment #14) > (In reply to comment #13) > > > > Thanks for the clarification, Jevgeni. I'm going to CC Scott on this bug to get > > his comments. > > > I remember we have already been discussing this issue with Scott for a while. > The hack solution for the development was to use local XMPP server, but there > were no workaround for users. As to implementing the proxy handling in ECF - at > that time there were more essential features to implement, so this issue, as > I've understand, had a lower priority. > Proxy handling has several aspects to it for XMPP. First and foremost is a specification of type of proxy/s desired. A 'default' is socks4 or socks5...we can relatively easily add socks 4 or 5 proxy support now that the org.eclipse.ecf.core.net.proxy API is in place (as of 3.3.0). But it would be helpful to have some indication of whether socks 4 or 5 is going to be sufficient for a reasonable subset of people's needs. In the mean time, we can now add support for socks4 and socks5...given some committer's time or actual contribution. (In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > > > > Thanks for the clarification, Jevgeni. I'm going to CC Scott on this bug to get > > > his comments. > > > > > I remember we have already been discussing this issue with Scott for a while. > > The hack solution for the development was to use local XMPP server, but there > > were no workaround for users. As to implementing the proxy handling in ECF - at > > that time there were more essential features to implement, so this issue, as > > I've understand, had a lower priority. > > > > Proxy handling has several aspects to it for XMPP. First and foremost is a > specification of type of proxy/s desired. A 'default' is socks4 or socks5...we > can relatively easily add socks 4 or 5 proxy support now that the > org.eclipse.ecf.core.net.proxy API is in place (as of 3.3.0). > > But it would be helpful to have some indication of whether socks 4 or 5 is > going to be sufficient for a reasonable subset of people's needs. > > In the mean time, we can now add support for socks4 and socks5...given some > committer's time or actual contribution. > I created bug #206275 for adding socks4-5 support (using org.eclipse.core.net.proxy API) to XMPP provider. This whole issue of proxying for ECF providers doesn't block work on this enhancement, BTW. If testing with XMPP is an issue for Jevgeni or anyone else we can use Skype or other providers for transport instead. I think that Jevgeni did the right thing by implementing all the core import/export and transfer facilities in a resource-based way, and all the work that he did should now be straightforward to adapt to ECF. I'm not sure what the right next step for that is or what the key use cases are. The Skype use case already works, and the user can drag tasks and queries to a Skype window. Perhaps the next step is to ensure that this drag-and-drop works for ECF views? (In reply to comment #17) > The Skype use > case already works, and the user can drag tasks and queries to a Skype window. > Perhaps the next step is to ensure that this drag-and-drop works for ECF views? Mik, you mean a Skype window from the official Skype client, right? And that invokes a file transfer I...guess? (In reply to comment #17) > I think that Jevgeni did the right thing by implementing all the core > import/export and transfer facilities in a resource-based way, and all the work > that he did should now be straightforward to adapt to ECF. I'm not sure what > the right next step for that is or what the key use cases are. The Skype use > case already works, and the user can drag tasks and queries to a Skype window. > Perhaps the next step is to ensure that this drag-and-drop works for ECF views? > ECF has an extension point for the contacts list view: org.eclipse.ecf.presence.ui.rosterViewerDropTarget This allows any to set itself up as a handler when items are dropped onto a given item in the contacts list (i.e. a buddy). The IRosterViewerDropTarget is the interface that extensions must implement. Here are the javadocs for this interface: http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/presence/ui/dnd/IRosterViewerDropTarget.html It would be up to the extension to decide what the right Mylar entity (shared task, task context, db file, etc) to share would be. The IRosterItem provided in the validateDrop gives access to ECF communications with the given remote. (In reply to comment #17) > I think that Jevgeni did the right thing by implementing all the core > import/export and transfer facilities in a resource-based way, and all the work > that he did should now be straightforward to adapt to ECF. Taking this into account, Jevgeni and Mik, do you want the ECF team to take over this bug now? (In reply to comment #20) > Taking this into account, Jevgeni and Mik, do you want the ECF team to take over > this bug now? That would be great! Just let us know what support you need from the Mylyn end. A rather primitive version of this functionality is in ECF's CVS repository under org.eclipse.ecf/plugins/org.eclipse.ecf.mylyn.ui under /cvsroot/technology. Please see this mailing list posting for more information. http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg01195.html In order for this functionality to work, we are assuming that both users have logged into an XMPP account (like Google Talk) in Eclipse via ECF. In terms of behaviour, when a task is received it is put into a queue to be imported later (at the user's convenience). But when that task is imported, should the task be activated immediately or simply added to the task list? Currently it activates immediately and I bring the point up because personally I would prefer the latter and there is a bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=236066) that I think will be fixed by changing this functionality. It could be filed into a new folder labeled 'newly imported tasks', left in the Unorganized folder or the task could be highlighted in the list but not activated, or anything else that seems logical (I like the highlight but not activate idea). Comments/other ideas? I think it would be better not to activate the task without asking the user. Task activation causes a major change in the workbench, and should only be done if the user intended it to happen. I imagine that there should be a convenient way to ask, e.g. via a separate dialog or a checkbox on an existing dialog. Although I would still like to see something like this, given changed focus, membership, unfortunately ECF doesn't have resources to work on this any longer. Resolving as wontfix. |