| RE: [corona-dev] use case |
Bryan, Based upon one of your previous postings, I do believe you do have a clue what Corona does. Its goal is to deliver a collaboration framework (1) based upon an Eclipse server-side environment (2). Corona's collaboration framework does utilise ECF for its communications. However, we use it for the communciation layer. The ECF examples of chat, file sharing, etc... are not integrated with Corona's collaboration framework. They are seperate plugin examples of how an application provider could leverage ECF's communication framework. I understood your use case to focused on how to share the gig (or two) of data using "Share...". Corona is focused on providing a common context for collaboration. In the scenario you descibed, this would be supported if the developers involved need to share the same context. The functionality you are asking for would be to utizie Corona's collaboration framework in order to participate in the same collaboration context. ________________________________ From: corona-dev-bounces@xxxxxxxxxxx on behalf of Bryan Hunt Sent: Thu 3/15/2007 3:58 PM To: Corona development Subject: Re: [corona-dev] use case Interesting ... I will do that. I guess this also means that I have no clue as to what corona does as I thought it was collaboration atop remote services. I guess I'll wait for a new write-up on corona and re-evaluate then. Thanks. Bryan On Mar 15, 2007, at 2:29 PM, O'Flynn, Dennis wrote: Bryan, The "Share..." functionality mentioned in this use case is provided by ECF (not Corona). You probably should post this use case to their dev list as well so that the ECF community can respond. -----Original Message----- From: corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Bryan Hunt Sent: Thursday, March 15, 2007 10:45 AM To: Corona development Subject: [corona-dev] use case 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. Bryan 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. _______________________________________________ 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.
<<winmail.dat>>