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 <mailto: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 <mailto:corona-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/corona-dev
