|[ecf-dev] Re: DocShare inconsistency|
Hi Jonas/all,I contacted my colleague that works on the jface text components (i.e. IDocument stuff), and here are some of his response to my question. I said:
"Basically, among other things we need to understand the synchronization conventions around access to IDocuments. If you have any info or pointers, it would be most appreciated." Kai responded:...In principle, synchronization in the text framework is weak. For a long time, the basic assumption has been that all access is in the UI thread. With quickdiff, spelling, and annotation update in the background this changed but only for those use cases. A good entry point is ISynchronizable. Document and AnnotationModel are implementing this interface. Look at the call sites for methods of it.
Scott Jonas Boetel wrote:
Hi,I'm a big fan of Operational Transformation and all excited to see it integrated into Eclipse. Needless to say that I immediately tried DocShare myself. I have read some papers about Operational Transformation before and I know that a lot of older implementations fail when it comes to corner cases.What I did is the following: 1. Shared an C++ document with a friend over Skype 2. Started editing non-overlapping sections (works great)3. Tried automatic code reformatting (works too, looks kind of funny seeing the changes dropping in one by one at the other site) 4. Tried automatic code reformatting while the other site is editing too (inconsistency occurred)From the Google talk I deduce that you already know about possible inconsistencies when using "high level" editing functions. I wanted to know if there is a problem with the Operational Transformation implementation (Cola) or with the integration into Eclipse or something else.I looked at the source code and my best guess is that Cola might be fine. I don't really know because of the tricky case when there is an insertion inside a deletion. What i stumbled upon where the synchronization mechanisms used for applying transformed operations to the document.If I understood it correctly DocShare works on an IDocument where it registered an IDocumentListener. I think this is a great idea because if you can get the low level document synced you can sync every document build upon it automatically. I also think that every document change triggers the according events. It should definitely be possible to reconstruct a single document just by listening to the change events and applying them on a local copy. Even when those changes are caused by high level edit operations.So if Cola is not the problem and DocShare isn't missing any changes and the communication channel is reliable, what is causing the inconsistencies? My guess is as follows: When DocShare integrates a remote operation it uses asyncExec to transforms it against the known local operations and to apply the transformed operation to the document. I say "known" local operations because I'm not sure if it's possible to have a race condition here.Is it possible to miss a document change while in asyncExec? Can there be document changes in non-UI threads? What if a local change happens while DocShare is in the "setEditorToRefuseInput(); [..] setEditorToAcceptInput();" block? The related question is: How do other edit operations guarantee consistency? For example the code reformatting mentioned earlier. How do those operations gain exclusive access to the underlying document? Is there some mechanism to acquire a mutex on an IDocument?The other question is: Are there plans to support more than two sites? I know that Operational Transformation gets really complicated because you need TP2 ( T(T(b,a),T(c,a)) == T(T(a,b),T(c,b)) ). In fact the only implementation i know of being able to guarantee TP1 & TP2 is the one with tombstones from Gérald Oster which basically never deletes anything. I'd like to offer my help in this regard.Thank you for your attention and patience. Jonas Boetel
Back to the top