Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Live Mesh and fine-grained version control of arbitrary data formats RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi,

    I know some people on this forum have requested a versioning system for files stored in Live Mesh.  What I'm wondering is a little different, though.

    I'm envisioning a system where various application vendors could write a conduit for their file format that would allow Live Mesh to sync and track versions of the files, but not just at the level of the file.  For example, the Microsoft Office team could write a conduit for Live Mesh that would allow it to utilize the track changes/compare features to reconcile changes to files, and Adobe (or a third party) could write a similar thing for Photoshop that would notice that you added a layer to your picture, while someone else modified an existing layer, allowing you to automatically and seamlessly merge the changes.

    Is this sort of thing possible given the architecture of the Live Mesh platform?  (I know nothing like this is implemented at the moment.)  I've read about FeedSync and such, so I imagine documents might need to be broken down into sub-feeds with each "unit" of information stored as a separate entry.  Is this correct?  What if there are multiple ways to break the document down, and all of them need to be supported for change-tracking?

    The reason this is so intriguing to me is that it's a whole order of magnitude above any current version control system, like Subversion, which often just deal with text files, don't support automatic sync, and are very specialized in what they do.  I'm hoping Live Mesh will enable a real synergy of file sharing, device connectivity, version tracking, and collaboration in a simple, elegant, and robust package.  Is this in line with your goals for the platform?
    Wednesday, May 21, 2008 10:23 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi aatreya,

    This is an *excellent* example of a possible usage of Live Mesh.  You are correct in that with the 'application'/experience that we have built on top of the platform today, Live Mesh Folders, the unit of replication is the [item representing the] file.  An entry in a feed is the unit of replication, however, it is really up to the application to decide what what that entry represents.  So certainly, one could imagine breaking down a "file" into multiple entries.  Note that there may be some additional complexities in dealing with cross-entry consistency issues.

    Hopefully we'll have a blog post or two about the underlying FeedSync architecture in the future that may clear up some of the "Is this possible?" questions.

    If you're interested in an early look at the developer SDK when it becomes available (to give a shot at implementing these cool scenarios you dream up), be sure to sign up here!

    Thanks,
    Richard
    Richard Chung [ Live Mesh ]
    Thursday, May 22, 2008 12:20 AM
    Answerer

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi aatreya,

    This is an *excellent* example of a possible usage of Live Mesh.  You are correct in that with the 'application'/experience that we have built on top of the platform today, Live Mesh Folders, the unit of replication is the [item representing the] file.  An entry in a feed is the unit of replication, however, it is really up to the application to decide what what that entry represents.  So certainly, one could imagine breaking down a "file" into multiple entries.  Note that there may be some additional complexities in dealing with cross-entry consistency issues.

    Hopefully we'll have a blog post or two about the underlying FeedSync architecture in the future that may clear up some of the "Is this possible?" questions.

    If you're interested in an early look at the developer SDK when it becomes available (to give a shot at implementing these cool scenarios you dream up), be sure to sign up here!

    Thanks,
    Richard
    Richard Chung [ Live Mesh ]
    Thursday, May 22, 2008 12:20 AM
    Answerer
  • Question
    Sign in to vote
    0
    Sign in to vote
    Not even having the api yet, I would still say yes.  Your conduit app would understand the file format of the files your talking about.  It would also understand how to break it up into parts or objects.  I would think things like Blend and Design would be more direct as everything is an object already.  The receiving "Connector" would just update the file as needed.  You as the dev, could use the feeds anyway you want - I would think of the feeds as more like a comm channel.  Myself, I would consider, in this case, feed items as transactions or units of work, but just a lazy stream of work units.  You may have to handle the conflict logic yourself maybe.  Maybe NTFS transaction file system and logging could take some of the work out of this, not sure if you could hook into it as needed however.  Makes one think that app files maybe should handled more like DB with transactions.  Add an object to Blend, and a log is created, etc - kinda like who Undo and Redo are implemented, but using persistent storage and transactions.  Interesting that remote sync could effect app file design of the future.
    Thursday, May 22, 2008 12:37 AM