Community
Participate
Working Groups
When I have a shared editor session initiated and want to open up a second one, nothing happens. Even after closing the shared editor, I cannot open up a second session. I have to disconnect from my provider (XMPP) and reconnect, and I'm able to open up a new session.
I'd say that this bug pretty much blocks bug 239048 in my opinion as since sharing at the resource-level is almost useless if you can only keep one document/editor in synch.
Currently, the docshare plug-in creates one DocShare instance per IChannelContainerAdapter with a single field for the editor, remote peer, and the likes. This is naturally insufficient and is the primary cause behind it being incapable of supporting the sharing multiple documents at a time. I see three solutions to this problem at the moment: ------------- 1) We create a DocShare instance for every document and every peer that it's shared with (see bug 240290). This minimizes code changes because the 1-to-1 assumption is kept (in a way). The IChannel ID would presumably be generated based on the two peers and the file's path. 2) A DocShare instance is created for every document and we keep a list of target IDs as third parties join and leave the session. This allows the same DocShare instance to distribute changes amongst the N peers for the single document (instead of having an N number of IDocumentListeners in 1). A unique IChannel ID would be generated based on the file's path. 3) Keep the implementation to use one DocShare instance per IChannelContainerAdapter. The DocShare class will need to be expanded to handle multiple target IDs and documents. Since there's only one instance, the DocumentChangeMessage would have to be updated to include some unique identifier for the IDocument in question as the remote peers would not be able to distinguish which document has been edited otherwise. ------------- For all of the solutions above, the invitation request from the initiator to the third party will have to include the list of IDs of all users that are currently editing the document so that change distribution works properly.
I like the idea of option 3. I think it also would be a step along the way of having full project/workspace synchronisation on a docshare instance. James
The screencast is kind of choppy (particularly the cursor) but it gets the point across. It is about seven megabytes so it will take a while to load, there is no audio. http://www.hantsuki.org/screencasts/ecf-team.htm The work above essentially overlaps with bug 239048. The code consists of: -three bundles, docshare2, resource synchronization core, resource synchronization ui -hacks -Cola synchronization strategy, refactored DocShare code (in docshare2) -file buffers and IDocument management (this allows changes in an editor to be propagated to B even if B does not have the editor up) -basic resource delta analysis for propagating resource changes to remote peers -more hacks, particularly ugly and simplistic code to ensure things are run on the UI thread if necessary (if an editor is up and the document is changed, UI thread yes, if no editor is up, UI thread no) -two IChannels, one for sending document changes, another for resource changes Features I hope to implement: -use a different colour for the remote user's _active_ editor -proper UI after clicking 'Share Project' so it doesn't "just happen (TM)" -need to merge the annotation code back, it is missing as you may have noticed, I removed it while making DocShare headless -TBD
Remy, If you haven't already, would you please announce this video on ecf-dev and link to it on wiki.eclipse.org/ECF...and if desired/appropriate, blog about it? Thanks, Scott (In reply to comment #4) > The screencast is kind of choppy (particularly the cursor) but it gets the > point across. It is about seven megabytes so it will take a while to load, > there is no audio. > > http://www.hantsuki.org/screencasts/ecf-team.htm > > The work above essentially overlaps with bug 239048. > > The code consists of: > -three bundles, docshare2, resource synchronization core, resource > synchronization ui > -hacks > -Cola synchronization strategy, refactored DocShare code (in docshare2) > -file buffers and IDocument management (this allows changes in an editor to be > propagated to B even if B does not have the editor up) > -basic resource delta analysis for propagating resource changes to remote peers > -more hacks, particularly ugly and simplistic code to ensure things are run on > the UI thread if necessary (if an editor is up and the document is changed, UI > thread yes, if no editor is up, UI thread no) > -two IChannels, one for sending document changes, another for resource changes > > Features I hope to implement: > -use a different colour for the remote user's _active_ editor > -proper UI after clicking 'Share Project' so it doesn't "just happen (TM)" > -need to merge the annotation code back, it is missing as you may have noticed, > I removed it while making DocShare headless > -TBD >
(In reply to comment #5) > If you haven't already, would you please announce this video on ecf-dev and > link to it on wiki.eclipse.org/ECF...and if desired/appropriate, blog about it? Done and done. I blogged about already on Sunday night actually. Selection propagation through annotations is now supported. I hope to work on the request/accept interface next. Haven't quite yet decided on how this should look though.
(In reply to comment #6) > (In reply to comment #5) > > If you haven't already, would you please announce this video on ecf-dev and > > link to it on wiki.eclipse.org/ECF...and if desired/appropriate, blog about it? > > Done and done. I blogged about already on Sunday night actually. > > Selection propagation through annotations is now supported. I hope to work on > the request/accept interface next. Haven't quite yet decided on how this should > look though. > Thanks Remy...sounds good. Mustafa, James, Marcelo...how does this fit in with the other plans WRT cola/RT shared editing? I'm assigning this but to Mustafa, as the lead committer for this area of work. Mustafa if it needs to be reassigned then please do so.
Created attachment 142298 [details] Archive file of the current code on my hard drive. Dunno how much I will be able to work on this in the future and its relevance and demand may also dwindle in the face of Google Wave (bug 280347). Nevertheless, I figured I'd publish the code here for the benefit of others in case someone wants to try a hand at this or would like to see how I went about implementing something. It goes without saying that it is not very well commented (har har) and people inspecting the code should have some basic knowledge about the resources and text APIs.
(In reply to comment #8) > Created an attachment (id=142298) [details] > Archive file of the current code on my hard drive. > > Dunno how much I will be able to work on this in the future and its relevance > and demand may also dwindle in the face of Google Wave (bug 280347). > > Nevertheless, I figured I'd publish the code here for the benefit of others in > case someone wants to try a hand at this or would like to see how I went about > implementing something. It goes without saying that it is not very well > commented (har har) and people inspecting the code should have some basic > knowledge about the resources and text APIs. > Hi Remy. How much (if any) of this code is in CVS somewhere? If significant parts are not already in CVS...if possible I would like to have it committed by you...in the incubation area if necessary...depending upon the maturity of things (in your judgment). Thanks.
(In reply to comment #9) > How much (if any) of this code is in CVS somewhere? At the moment, none of it is in CVS.
Comment on attachment 142298 [details] Archive file of the current code on my hard drive. I've thrown all three modules into CVS under the incubation module. In hindsight I should've named the docshare2 bundle org.eclipse.ecf.sync.documents or something like that but oh well, that can be discussed when and if it leaves incubation. I've been told that two people editing the document at the same time works though when I tried to demo it with Andrew it didn't work out. I may have introduced problems in my copy/pasting of docshare when I made it headless, I can't say.
Resolving as wontfix due to limited resources. If contributors or committer resources become available for additional work in this area then please reopen.
