Bugzilla – Full Text Bug Listing
| Summary: | reporting progress from a command | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Rafael Chaves <eclipse> |
| Component: | Client | Assignee: | Malgorzata Janczarska <malgorzata.tomczyk> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | malgorzata.tomczyk, simon_kaegi, susan, Szymon.Brandys |
| Version: | 1.0 | ||
| Target Milestone: | 2.0 M2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Rafael Chaves
Agree completely, there are several services we imagine plugins would want to call (status/message, progress, dialog, etc.) but we've just not had someone writing a plugin who pushed us on the use case. We've intentionally not wanted to expose API to the "shell services" without a real plugin case. Sounds like you have one! Can you describe the plugin/what the command does and what you'd want to report? This would be a post 1.0 work item Thanks. My plugin contributes a "Deploy application" action, which is a long-running operation. Right now the user has no means to know: a) that the action was actually triggered (it is easy to click on the wrong place) b) what the outcome of the action was (do I have a new version deployed or do I have to fix something and try again?) c) ideally, where in the operation are we right now (compiling, uploading, stopping server, deploying artifact, restarting server), but this is a nice to have. [As a matter of fact, I am finding really hard to do a bunch of stuff from a plugin because they have so little available (no access to services). It seems the only way to avoid that is to provide one's own pages but I don't think I should have to do that. If the concern is security, maybe there should be a different handling of trusted and untrusted plugins] We should work on this post 1.0 for sure. See also bug 371157 which discusses user prompting. I could imagine us doing - status messages - progress messages - user prompts together. We realize how hard it is to be a plugin, the "don't call us, we'll call you" model. We just haven't had someone pushing us hard on fixing this. fyi...there is some discussion of where we need to go here: adventuresinthoughtlessness.blogspot.com/2012_03_01_archive.html This post was focusing on visual plugins but the section "Toward a two-way street" really applies to any plug-in. Susan, any plans to address this (hopefully early) post 1.0? This gap is a show stopper for plugins contributing commands for long running operations. Right now, I need to tell users to wait some time after triggering a long running operation. And there is no way for them to tell whether the operation succeeded or failed. yes, I've got "shell services" on the list and this looks like a good use case. Need to talk to Simon a bit about it. (In reply to comment #3) > We should work on this post 1.0 for sure. See also bug 371157 which > discusses user prompting. I could imagine us doing > - status messages > - progress messages > - user prompts > > together. We realize how hard it is to be a plugin, the "don't call us, > we'll call you" model. We just haven't had someone pushing us hard on > fixing this. I'm not sure if services in plug-ins should have access to progress service. The way how long-running tasks should report the progress is: - the service method should return a task (see 392798) - the caller of the service should report that the method is run/finished - reporting should be made based on the task status We do it this way for Git methods. We used to have progress reporting inside gitClient.js where methods are mostly long-running xhr calls. Then we moved all the progress reporting to gitCommands.js which are commands callings methods from gitClient.js. Good example why not to report from services in plug-ins is filesystem service. A method to get the list of folders could be called in many contexts and each time the caller should decide how to report it. On today's Orion call there was discussion about the new operations API. Gosia is going to update some extension points to report progress. That should clarify whether this bug is already done (?) or what work needs to happen. Gosia, I'm marking this M2 since I know you are doing "something" in this space, but feel free to either close this bug as duplicate or change milestone if this represents more than what you are planning. I'm marking this a duplicate of bug 392798, because essentially this bug is a part of bug 392798. Please take a look at this wiki page: http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Long_running_operations_in_services_and_plugins it contains examples how to track long running operations started in commands plugged into the editor. *** This bug has been marked as a duplicate of bug 392798 *** |