[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [flux-dev] Status update
|
On 8/4/2016 10:20 AM, Vershinin Fjodor wrote:
Hi!
GSOC final evolution is approaching, and I am little bit worried about
how to present the work I have done in this project. The biggest
problem is that my work was mostly in research field, so it's hard to
summarize and it's easy to get lost during the research process.
However, it's time to make final spurt in order to get something
delivered to Eclipse Community, so I'm ready to hear some proposals,
where I can put some effort in.
Currently, I am trying to implement the mechanism that detects changes
among synced flux clients. What should happen if the receiver has file
not in the same state? I would like to know more about how history of
changes should work in that case.
What about merging logic of file system synchronization. Eclipse flux
plugin implementation and Flux file watcher implementation are using
the same code to build messages and send to flux and receive messages.
Should I change the way of message construction in flux codebase in
the same way, like it is done in the flux file watcher or not?
You might want to consult some of the work that ECF did a long time ago
based upon operational tranformation:
https://wiki.eclipse.org/RT_Shared_Editing
This was used to implement an Eclipse-based shared editor with
consistency maintenance:
https://vimeo.com/1195398
The API that came of this the ECF 'sync' API...along with the cola
shared editing app is still in ECF
https://wiki.eclipse.org/Extending_Real-Time_Shared_Editing_for_Use_with_Other_Editors
FWIW, I understand that operational transformation is what Google uses
for shared editing in Google docs, spreadsheets, etc. I'm not sure
whether that's still true, but that's what I've heard.
Scott
