[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Questions on COLA
- From: Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>
- Date: Fri, 20 Feb 2009 09:39:04 -0800
- Delivered-to: email@example.com
- User-agent: Thunderbird 126.96.36.199 (Windows/20081209)
Before I throw the questions at you I want to give major kudo’s for
all of what ECF offers especially COLA. I am currently looking at some
areas of ECF to build collaboration tooling and have a few questions
1. Before I dig into the code to enable this, is there a reason to
only allow one file at a time to be shared?
2. Is there a reason that the compare editor’s could not be shared,
I am assuming this may also have to do with the answer to the
The answer to both of these questions (i.e. reason for one editor at a
time) is fundamentally the same: simplification. Sharing only one file
at a time simplifies things (both in terms of the user interface and in
terms for the implementation/communication for synchronization)...the
work on docshare that was done last year was done by only a few people
part-time. (thanks Remy...the bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=238966 is a more technical
description of the single-editor issue). Also, as Remy points out, he
has been doing some recent work on implementing the platform team API
using ECF (see his post) and this might be relevant for some of your
requirements. This work is already in ECF 3.0.
Having said that, we are current gearing up for a renewed/increased
technical effort on docshare/cola...including work in a number of areas.
One thing that has happened over the last 9 months is that we have
created a separation between the docshare user interface and the
synchronization algorithm (cola). For reference, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=234142. We have
implemented what we are calling a 'sync' api (in bundle
org.eclipse.ecf.sync), with cola as the underlying implementation.
Further, docshare for ECF 3.0 has been ported over to use the sync API.
This sync api has a number of advantages...for example, it can/could be
use in other applications (i.e. not docshare)...but rather other shared
editors (like ones that use multiple editors, different model forms like
graphical editors, etc).
Actually, Mustafa, Marcelo and myself are just now re-gearing up for
additional work on docshare/sync API, etc. and would welcome both input
about what things people want most out of this area (please open
bugs/enhancements), and we are also looking for technical contributions
(i.e. contributors who would be willing to work on new/additional code
that can/could become part of ECF). So if you are able and willing to
work with us, and contribute the code to the project (under EPL), we
would very much appreciate your participation (this applies to everyone
reading this). BTW, although people who can/would do coding are
terrific, we would also appreciate help in other areas...e.g.
documentation, testing, etc. We are somewhat limited, however, so our
promises may not meet all the desireds.
So just let us know a) what you want; b) what you might be willing to
contribute and as a community we'll do all we can to deliver.
I am thinking of using cola in a code review type of scenario but for
that I would need to know that at least question 1 would be possible.
I would like to visually represent the reviewee’s project in a view in
the reviewers workbench. Essentially the reviewee would initiate the
sharing of the project and the reviewer would decide which files to
ecf-dev mailing list