Bug 239048 - [modelsync][rtcollab] Distribute resource changes to peer in real-time
Summary: [modelsync][rtcollab] Distribute resource changes to peer in real-time
Status: RESOLVED FIXED
Alias: None
Product: ECF
Classification: RT
Component: ecf.cola (show other bugs)
Version: 2.0.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 3.0.0   Edit
Assignee: ecf.core-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: plan
: 238975 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-06-30 15:44 EDT by Scott Lewis CLA
Modified: 2018-06-11 12:20 EDT (History)
7 users (show)

See Also:

Attachments
Image of an implementation of the datashare/modelsync APIs on top of the Platform's Resources and Team APIs. (74.59 KB, image/gif)
2008-11-28 02:41 EST, Remy Suen CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Lewis CLA 2008-06-30 15:44:58 EDT 
Currently, ECF does not distribute or synchronize workspace resources.  Being able to do so would allow for more compelling real-time collaborative editing (e.g. see bug #238975) as well as a number of other team-collaboration features.

There are a number of UI and design issues coming out of such a feature.  We can use this enhancement request to keep track/list them.
Comment 1 Remy Suen CLA 2008-11-23 03:34:29 EST 
Scott, I have been working on an org.eclipse.ecf.sync.resources and an org.eclipse.ecf.sync.resources.ui plug-in locally and would like to commit it to CVS.

Should it go in framework/bundles/? Are you okay with these plug-in names?
Comment 2 Remy Suen CLA 2008-11-28 02:41:19 EST 
Created attachment 118976 [details]
Image of an implementation of the datashare/modelsync APIs on top of the Platform's Resources and Team APIs.

If we were able to reuse the 'Synchronize' view, synchronization should become a lot easier for two arbitrary resources prior to sharing them as it would then pretty much be assumed that the two resources are in synch and the amount of volatile changes on either end will be minimized.
Comment 3 Remy Suen CLA 2008-12-01 02:11:13 EST 
(In reply to comment #2)
Further discussions on the 'Synchronize' view work should go in bug 257017. I'd like to keep this bug for talking about distributing resource changes and the likes using the sync API.
Comment 4 James Sugrue CLA 2009-02-03 10:19:29 EST 
Remy, for this item, would it be possible to consider the option that only one user has the project, so the complete project is sent over to the remote user when sharing is initiated?
It may seem overkill, but I'm thinking small projects.
Comment 5 Remy Suen CLA 2009-02-03 14:24:54 EST 
(In reply to comment #4)
> Remy, for this item, would it be possible to consider the option that only one
> user has the project, so the complete project is sent over to the remote user
> when sharing is initiated?
> It may seem overkill, but I'm thinking small projects.

So when you invoke the share the entire project is automatically sent over? The reverse operation of downloading the project (instead of uploading it) is technically covered by the Team provider implementation we are offering.
Comment 6 Scott Lewis CLA 2009-05-12 18:55:14 EDT 
*** Bug 238975 has been marked as a duplicate of this bug. ***
Comment 7 Scott Lewis CLA 2009-05-28 19:03:33 EDT 
With Remy's work on the team provider I suggest that he resolve this bug as fixed.  There is clearly more to do here, as discussed on the mailing list and elsewhere, but I think a new bug/bugs should be opened for specific resource sharing features.
Comment 8 Remy Suen CLA 2009-05-28 19:17:47 EDT 
For project sharing, please refer to bug 238966.