| RE: [corona-dev] use case |
|
The “Share…” functionality mentioned in this use case
is provided by ECF (not -----Original Message----- Here's a collaboration use case for consideration. If we could solve this problem, it could greatly increase the productivity of our customers. A user checks out one or more Eclipse projects from subversion or perhaps creates new project(s). The user makes modifications to the contents of the project(s). The user runs an external program that uses the Eclipse projects as input, and produces artifacts in a specified location that is not an Eclipse project. The status of the process execution is displayed in an eclipse view (along with the status of previous executions). The process fails to produce the expected results. The user determines that the root cause is in one of the Eclipse projects and that data is owned by another developer. The user selects the process status in the eclipse view, right-clicks and selects "Share...". The user then selects the developer
who needs to debug the root cause. The target developer receives a notification that there is a problem that needs to be debugged. The developer accepts the problem and the status of the failing process is loaded into their Eclipse view as if they had originally run the process. They re-run the process, debug the fail, and fix the bad inputs in the Eclipse project(s). They right-click the status of the, now passing, process and select "Fixed". The fixed inputs are sent back to the originator. Some interesting problems with this use case: If the originating developer is using a local sandbox for his workspace, how does the receiving developer get the contents. If the receiving developer is in the middle of modifying those same Eclipse projects, do they have to switch worspaces? The incoming projects can't overwrite their current modifications. What if the originating developer needs to modify those projects while waiting for the receiving developer to fix the problem? The original data must be preserved so the receiving developer can reproduce the fail. If the originating developer re-runs the process, the new artifacts must be placed in a different output directory to preserve the original, failing, artifacts. Consideration must be given to the amount of data shared / moved - it's not uncommon for us to have a gig or two of input / output data surrounding a process. Support for a shared filesystem such as AFS may be necessary as part of a solution to these problems. PS ... It seems that I will be best served to understand the basics of OSGi, followed by ECF to use as a foundation for our remote services use case, and then work on understanding the corona context container?? to serve this new use case. Suggestions? _______________________________________________ corona-dev mailing list corona-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/corona-dev The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. |