I'd like to add that I hope we will have one day ECF
collaboration
capabilities integrated. This is just a matter of
integrating and
handling ECF settings in our context container. But this
requires some
work, for which we didn't have time yet :(
Marcin
Bryan Hunt wrote:
> 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 eclipse.org
>> [mailto:corona-dev-bounceseclipse.org] 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-deveclipse.org <mailto:corona-deveclipse.org>
>>
>> h
ttps://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-deveclipse.org <mailto:corona-deveclipse.org>
>> h
ttps://dev.eclipse.org/mailman/listinfo/corona-dev
>
>
------------------------------------------------------------
------------
>
> _______________________________________________
> corona-dev mailing list
> corona-deveclipse.org
> h
ttps://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-deveclipse.org
h
ttps://dev.eclipse.org/mailman/listinfo/corona-dev
|