<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Team Synchronizing</title>
  <meta http-equiv="Content-Type"
 content="text/html; charset=iso-8859-1">
  <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css"
 type="text/css">
</head>
<body bgcolor="#ffffff" text="#000000">
<table border="0" cellspacing="5" cellpadding="2" width="100%">
  <tbody>
    <tr>
      <td align="left" valign="top" bgcolor="#0080c0"><b><font
 color="#ffffff" face="Arial,Helvetica"> Eclipse Team Component</font></b></td>
    </tr>
    <tr> 
      <td> <h1>Improving the Team Synchronize support</h1>
        <p>This document outlines how other plug-ins can participate in the Synchronize 
          View and how the Synchronize View is being refactored for Eclipse 3.0. 
          Interested parties should review this document and verify that their 
          use-cases are addressed and that the solution satisfies their needs.</p>
        <p>The work on the Sychronize View is being done to support the following 
          3.0 plan items:</p>
        <ul>
          <li> <a
 href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37705">37705</a> Improve 
            team API<br>
            <br>
            In addition to supporting a generic headless Team API numerous plug-ins 
            are also interested in using the Synchronize technology. Currently 
            the CVS plugin uses this support but we haven't officialy made it 
            available for others. We feel that this is a complicated piece that 
            could be re-used by many other Team plug-ins to provide rich integration 
            of their tool into Eclipse.<br>
            <br>
          </li>
          <li> <a
 href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36957">36957</a> Support 
            concurrent activities<br>
            <br>
            The Synchronize operation is an excellent candidate for running in 
            the background. Some changes are required to the sync model to accomodate 
            concurrent calculation of resource synchronization.</li>
        </ul>
        <p>This document doesn't cover JSR-147 or CVS concurrent operations.</p>
        <p>Last Modified: February 24th, 2004</p>
        <h1>Motivations</h1>
        <p>As stated above, there are two motivating reasons for the 3.0 work 
          relating to the Team Synchronize APIs: (1) to enhance workflows, (2) 
          to provide an API for other plug-ins to use. Note that synchronization 
          support doesn't exclusively imply that the Synchronize View is used 
          to display and manipulate the synchronization states. Instead, it is 
          our intention to provide a framework for creating, managing, and then 
          finally displaying this synchronization state. The presentation of the 
          synchronize states can be flexible, and could be then shown in either 
          the Synchronize View, or in other more appropriate places (e.g. editors, 
          dialogs, wizards). </p>
        <p>This is a key for Team plug-ins for rich integration into Eclipse. 
          The motivations for the proposed workflow changes changes are described 
          below.</p>
        <h3>Dynamic syncrhonization model support<br>
        </h3>
        <p>One of the most important changes we are proposing is to migrate from 
          a static sync model to a dynamic one. Previously, a user would synchronize 
          a set of resources with their remotes and subsequent changes made in 
          the workspace would only be reflected in the synchronization state shown 
          in the view if the user explicitly re-synchronized. This also meant 
          that you could not browse local changes without running a potentialy 
          long operation. This static model also caused problems if we wanted 
          to refresh the remote state in the background and incrementally update 
          the sync model as remote changes were found.<br>
        </p>
        <h3>Synchronize View re-use</h3>
        <p>The view should support showing multiple types of synchronization targets. 
          The old sync view was re-used by clients but the synchronization state 
          of the previous type was lost. For example, synchronizing with a Dav 
          server then again with CVS. We are currently evaluating ways of providing 
          a view that shows different contexts. Some of the options are to have 
          a dropdown to select the different subscribers or to have a tabbed view. 
          I like the drop down because it takes less screen real estate and you 
          don't have the tab problem of truncating the titles.</p>
        <h3>Flexible Presentation of Synchronization state</h3>
        It should be possible to display synchronization states of local resources 
        in logical models that don't necessarily mirror the physical hierarchical 
        file system layout. In addition, it should be possible to display this 
        model to the user in other contexts than in the Synchronize View itself 
        (e.g. editor, embeded compare editor, wizard, dialog).<br> <h3>Background 
          event handling</h3>
        The synchronization UI should be responsive and support incremental updating 
        that won't interrupt the users workflows. For example, when changes are 
        made either to local workspace resources or to the sync model the changes 
        should be processed asynchronously. 
        <h3>Background fetching of remote state</h3>
        <p>Currently when a project is synchronized the complete remote tree is 
          fetched and a progress dialog is shown. The user can't perform any other 
          operation while the remote tree is fetched. There is no reason why this 
          couldn't be fetched in the backgroup without blocking the UI and would 
          allow an awareness of what other people in the team are working on and 
          help reduce the time needed to find out what others are doing.</p>
        <h3>Combine Synchronize/Merge/Compare</h3>
        <p>The terminology and look and feel of the CVS merge editor, compare 
          editors, and sync view is different. Basically a merge is the same as 
          synchronizing except for the fact that you can't commit changes. Merging 
          is already a tricky operation and having a conflicting usage model between 
          the sync and merge makes it even harder. (<a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35577">35577</a>)</p>
        <h3>Compare criterias</h3>
        <p>The comparison criteria that is used to calculate the sync state is 
          hidden from the user and it isn't obvious for them when the criteria 
          should be changed and what advantage it will have. This is also seen 
          when a user synchronizes a project against an existing project on the 
          server and notices that most files are conflicting. There is no easy 
          steps for calculating the 'real' changes. This may be solved by individual 
          Team plug-ins, but it is worth noting that it is a problem encountered 
          in the Synchronize View. (<a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=24887">24887</a>, <a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=21612">21612</a>, <a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=28143">28143</a>) </p>
        <h3>Splitting the Synchronize View from the Compare components</h3>
        <p>We would like to split the Synchronize view from the compare components 
          and have a dedicated view that shows synchronization state in different 
          forms and then allow the user to browse the changes using the compare 
          editors. Here is a list of motivating reasons for the split:</p>
        <ul>
          <li>Would like to use <em>real</em> editors for merging instead of the 
            <em>neutered</em> ones currently used. For example, the java editor 
            shown in the sync view looks real (e.g. syntax coloring) but is a 
            scaled down java editor. This causes integration and context problems 
            because it is very useful to try and write code in these editors without 
            resorting to opening the file with the real java editor. Then going 
            back to the sync view only to find that the file hasn't refreshed. 
          </li>
          <li>We wanted more flexibility in showing resource synchronization in 
            different ways: table, tree, tabletree, split view with statistics.... 
            Currently the compare DiffTreeViewer subclasses must be a tree and 
            this limits our implementation flexibility. </li>
          <li>The edit/save workflow in a view has always been strange. You couldn't 
            edit, look at another file, then return to your edit without being 
            forced to save the change first. This is not intuitive behavior, and 
            nowhere else in the platform are your forced to save changes just 
            to see another file. </li>
          <li>It made sense to use a perspective to accomplish what the old sync 
            view did by showing all related views (structure diff, structure compare, 
            merge viewers) together.</li>
        </ul>
        <h3>Show helpful change counts</h3>
        <p>It would be helpful for the user to understand the scope of changes 
          that are remote (incoming) and local (outgoing) regardless of the filters 
          being applied to the changes. This would help cases were users forget 
          changes because they have been filtered out of the view.</p>
        <h3> Working Sets</h3>
        <p>Because the Synchronize view can show the changes for all resources 
          in the workspace that are configured with the current synchronization 
          target the user can use working sets to scale the list of projects to 
          synchronize. When a working set is active the change counts change to 
          show both the counts in the current working set and those in the entire 
          workspace. This can help decide when to disable a working set.</p>
        <p>The&nbsp;CVS commands that used to prime the Synchronize View now use 
          a dynamically created working set to automatically reduce the list of 
          projects in the view. For example, when sharing a project for the first 
          time or synchronizing via the Team &gt; Synchronize with Remote menu, 
          a working set is created.</p>
        <h3>Conflicts are propagated to parent folders</h3>
        <p>To ensure that conflicts are never ignored, the conflict icon is propagated 
          to parent folders. This will also allow users to quickly find the conflicts.</p>
        <h3>General usability enhancements<br>
        </h3>
        <p>The structure compare part of the 2.1 Synchronize View has many usability 
          problems that we would like to improve.</p>
        <ul>
          <li>We propose that synchronization state be displayed in different 
            formats (table, compressed tree) so that things you are interested 
            in (the leaves of the tree) are not constantly separated by a great 
            distance. This would make it easier to see at a glance what has changed. 
            It also makes multi-selection operations less painful, for example 
            comitting a set of related files that should have the same comment. 
            (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=12453">12453</a>, 
            <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=16249">16249</a>) 
          </li>
          <li>There are several also several expansion/selection usability problems 
            that we would like to fix. (<a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=35187">35187</a>, <a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=33041">33041</a>, <a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=4931">4931</a>, <a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=5431">5431</a>, <a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=20847">20847</a>, <a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=27237">27237</a>, <a
 href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=16249">16249</a>) </li>
          <li>Synchronize view modes (filtering) and conflict workflows must be 
            improved. This is somewhat related to showing helpful change counts. 
            (<a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=10556">10556</a>, 
            <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=9451">9451</a>, 
            <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=139">139</a>, 
            <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=19712">19712</a>)</li>
        </ul>
        <h1>The Synchronize API</h1>
        The API is composed of both core and ui components. Firstly, the core 
        building blocks for synchronization is the management of synchronization 
        state of local resources. Synchronization state is usually modeled as 
        the change between a local resource and one or more <span
 style="font-style: italic;">variants </span>of that resource. Thus, the core 
        APIs are focused on managing variants (e.g. given a local resource what 
        is the variant used to calculate synchronization state) and how synchronization 
        state is calculated given a local resource and associated variants.<br> 
        <br>
        Given the physical representation of resource variants then the UI aspect 
        of the API allow you to control how the model is presented to the user. 
        Since the core synchronization classes are event driven, you can build 
        synchronization UIs that optionally update dynamically. Integration into 
        the Synchronize View is possible by using the synchronize view extension 
        points and using the synchronize APIs to and possibly re-usable UIs to 
        build the synchronize page.<br> <br>
        The interesting API packages are:<br> <h3>org.eclipse.team.core.synchronize</h3>
        <p>This package specifies the API for managing the synchronization state 
          between the local workspace resources and a corresponding variants of 
          those resources. The classes in this package can be used by Subscribers 
          (see the org.eclipse.team.core.subscribers package) or others. The classes 
          are roughly divided into three categories:</p>
        <ul>
          <li>describing the synchronization state of a one or more resources,</li>
          <li>notifying interested parties of changes in the synchronization state.</li>
          <li>filtering a set of resource based on a sync state criteria</li>
        </ul>
        <h3>org.eclipse.team.core.subscribers</h3>
        <p>This package specifies the API for Team subscribers. A Subscriber provides 
          access to the synchronization state between the local workspace resources 
          and a set of variants of those resources, whether it be a code repository 
          or some other type of server (e.g. FTP). A subscriber is typically associated 
          with only a subset of the resources in the local workspace, referred 
          to as the set of resources the subscriber supervises. The supervised 
          local resources have a corresponding variant state which describes the 
          state of the variant resources that correspond to the local resources.</p>
        <p>A Subscriber provides:</p>
        <ul>
          <li>a set of root resources that define the subset of resources in the 
            workspace that the subscriber supervises (some children of the roots 
            may not be supervised, as indicated by the isSupervised method).</li>
          <li>access to the synchronization state (using SyncInfo) between the 
            resources it supervises and their corresponding variant resources.</li>
          <li> the ability to refresh the the remote state. This implies that 
            the Subscriber would be responsible for caching variants.</li>
          <li>change notification to registered listeners (of type ISubscriberChangeListener) 
            when the variant state changes or when roots are added or removed.</li>
        </ul>
        <h3>org.eclipse.team.ui.synchronize</h3>
        <p>The packaage specifies a set of classes and interfaces to support participating 
          in the Synchronize View. Synchronize participants are declared by extending 
          the <strong>synchronizeParticipants </strong>extension point. There 
          are two classes of synchronize participants: <em>static </em>participants 
          will be created when the synchronize view is created, and <em>dynamic</em> 
          participants that are created by user code at some other time. A synchronize 
          manager (<b>ISynchronizeManager</b>) manages all active synchronize 
          participants, and provides notification of participants which are added 
          and removed. Participants are displayed in a page book view. Each participant 
          implementation is reponsible for creating its page (<b>IPageBookView</b>), 
          which provides freedom of presentation to the synchronize view implementation. 
          A single participant may be displayed simultaneously in multiple synchronize 
          views, and in different workbench windows.</p>
        <h3>org.eclipse.team.ui.synchronize.viewers</h3>
        <p>This package contains classes that support displaying synchronization 
          information described by SyncInfo. If you consider the synchronization 
          model described by the classes in <span style="font-style: italic;">org.eclipse.team.core.synchronize</span> 
          as the physical representation of resource variants then the classes 
          in this package allow you to control how the model is presented to the 
          user. One key feature of these APIs is that they support managing dynamic 
          models.<br>
        </p>
        <p>There is no specific support for the Synchronize View in this package. 
          Instead, the classes here can be used to build a page that can be shown 
          in the view, but they can also be used to show synchronization information 
          in dialogs, wizards, and editors.<br>
        </p>
        <h3>org.eclipse.team.ui.synchronize.subscribers</h3>
        <p>This package contains a classes that <span
 style="font-weight: bold;"></span> provides an implementation of a synchronize 
          participant that enables synchronization for a <b>Subscriber</b>. For 
          providers that implement a <strong>Subscriber</strong>, this is the 
          easiest method of integrating into the Synchronize View. The TeamSubscriberParticipant 
          provides a view of changes (incoming, outgoing, conflicting), modes 
          for showing only a subset of the changes, decorations for identifying 
          the changes, and working sets.<br>
        </p>
        <h1>How-To Guide</h1>
        <p>This section describes how to make use of the Synchronize API including 
          how to integrate into the Team Synchronize view. It is divided into 
          two parts. The first describes how to implement a Subscriber, either 
          from scratch or by building on top of an existing local workspace synchronization 
          infrastructure. The second part describes how to make use of the UI 
          components of the Synchronize API for showing Subscriber state in the 
          Team Synchronize view and other views, editors and dialogs.</p>
        <h2>Implementing a Subscriber</h2>
        <p>This section presents a few different perspectives on implementing 
          a subscriber. First, the general anatomy of a subscriber is discussed, 
          followed by a few examples that build on API provided in the <em>org.eclipse.team.core</em> 
          plugin.</p>
        <h3>The Anatomy of a Subscriber</h3>
        <p>A subscriber provides access to the synchronization state between the 
          local workspace and another location that mirrors the local workspace 
          resources. This other location is usually, but not necessarily, on a 
          different machine such as a server. In order to describe what a subscriber 
          is, we must first present some of the terminoligy we are going to use:</p>
        <blockquote> 
          <p><em>Resource Variant</em>: A local resource that is mapped to a resource 
            that exists at another location can be referred to as a variant of 
            that resource. That is, the resources are usually very similar but 
            may differ slightly (either due to modificatons to the local resource 
            or changes made the remote copy made by other users). We take a local 
            workspace centric view of this, referring to the local copy as the 
            resource and any remote copy as resource variants.</p>
          <p><em>Two-way vs. Three-way Synchronization</em>: There are two basic 
            types of synchronization state determination: two-way and three-way. 
            A two-way comparison only considers the local resource and a single 
            resource variant, referred to as the remote resource variant. This 
            type of comparison can only show the differences between the two resources 
            but cannot offer hints as to how the changes interelate. Most code 
            repository systems support a three-way comparison for synchronization 
            state determination. This type of comparision involves the local resource, 
            a remote resource variant and a base resource variant. The base resource 
            variant represents a common ancestor for the local and remote resources. 
            This allows for more sophisticated synchronization states that indicate 
            the direction of the change.</p>
        </blockquote>
        <p>A subscriber can then be described as providing access to the synchronization 
          state between the resources in the local workspace and a set of resource 
          variants for these resources using either a two-way or three-way comparison, 
          depending on the nature of the subscriber. A subscriber provides the 
          following capabilities:</p>
        <blockquote> 
          <p><strong>local workspace traversal</strong>: a subscriber supports 
            the traversal of the local workspace resources that are supervised 
            by the subscriber. As such, the subscriber has a set of root resources 
            that define the workspace subtrees under the subscriber's control, 
            as well as a <em>members</em> method that returns the supervised members 
            of a workspace resource.</p>
          <p><strong>resource synchronization state determination</strong>: For 
            supervised resources, the subscriber provides access to the synchronization 
            state of the resource, including access to the variants of the resource. 
            For each supervised resource, the subscriber provides a <em>SyncInfo</em> 
            object that contains the synchronization state and the variants used 
            to determine the state. The subscriber also provides an <em>IResourceVariantComparator</em> 
            which determines whether two-way or three-way comparison is to be 
            used and provides the logic used by the <em>SyncInfo</em> to comparing 
            resource variants when determining the synchronization state.</p>
          <p><strong>refresh of synchronization state and change notification</strong>: 
            Clients can react to changes that happen to local resources by listening 
            to the Core resource deltas. When a local resource is changed, the 
            synchronization state of the resource can then be re-obtained from 
            the subscriber. However, clients must explicilty query the server 
            to know if there are changes to the resource variants. For subscribers, 
            this process is broken up into two parts. A client can explicitly 
            <em>refresh</em> a subscriber. In response the subscriber will obtain 
            the latest state of the resource variants from the remote location 
            and fire synchronization state change events for any resource variants 
            that have changed. The change notification is separate from the refresh 
            since there may be other operations that contact the remote location 
            and obtain the latest remote state.</p>
        </blockquote>
        <p>As stated above, the purpose of the Subscriber API is to provide access 
          to the synchronization state between the local workspace and a remote 
          location. Obviously, underneath the hood, their must be an infrastructure 
          for managing that state. In general, the synchronization state consists 
          of the following basic states.</p>
        <ul>
          <li><em>local resource is synced with the remote</em>: when a resource 
            is loaded from or written to a remote location, it is consider in-sync 
            with the remote variant. At this point, the local timestamp and remote 
            timestamp are recorded to support future synchronization state checks.</li>
          <li><em>local resource is modified</em>: If the recorded in-sync local 
            modification timestamp differs from the actual timestamp, the resource 
            is locally modified.</li>
          <li><em>remote resource is modified</em>: If the timestamp of the remote 
            resource variant differs from the recorded remote timestamp, then 
            the resource has been remotely modified (most likely by a 3rd party).</li>
        </ul>
        <p>The infrastructure that maintains the states must persist the timestamps 
          obtained when a resource is synced.</p>
        <h3>Implementing a Subscriber From Scratch</h3>
        <p>When implementing a subscriber from scratch, you can make use of some 
          helpful API provided in the <em>org.eclipse.team.core</em> plugin. The 
          <em>org.eclipse.team.core.variants</em> package contains two subclasses 
          of <em>Subscriber</em> which can be used to simplify implementation. 
          The first is <em>ResourceVariantTreeSubscriber</em> which will be discussed 
          in the second example below. The second is a subclass of the first: 
          <em>ThreeWaySubscriber</em>. This subscriber implementation provides 
          several helpful classes for managing the synchronization state of a 
          local workspace. If you do not have any existing infrastructure, this 
          is a good place to start. </p>
        <p>Implementing a subscriber from scratch will be illustrated using our 
          file system example available in the <em>org.eclipse.team.examples.filesystem</em> 
          plugin. The code in the following description is kept to a minimum since 
          it is available from the dev.eclipse.org repository. Although not technicaly 
          a three-way subscriber, the file system example can still make good 
          use of this infrastructure. The FTP and WebDav plugins also are built 
          using this infrastructure.</p>
        <h4>ThreeWaySubscriber</h4>
        <p>For the file system example, we already had an implementation of a 
          <em>RepositoryProvider</em> that associated a local project with a file 
          system location where the local contents were mirrored. <em>FileSystemSubscriber</em> 
          was created as a subclass of <em>ThreeWaySubscriber</em> in order to 
          make use of a <em>ThreeWaySynchronizer</em> to manage workpace synchronization 
          state. Subsclasses of this class must do the following:</p>
        <ul>
          <li>create a <em>ThreeWaySynchronizer</em> instance to manage the local 
            workspace synchronization state.</li>
          <li>create an instance of a ThreeWayRemoteTree subclass to provide remote 
            tree refresh. </li>
          <ul>
            <li>The class <em>FileSystemRemoteTree</em> was defined for this purpose</li>
          </ul>
          <li>implement a method to create the resource variant handles used to 
            calculate the synchronization state. 
            <ul>
              <li>The class <em>FileSystemResourceVariant</em> (a subclass of 
                <em>CachedResourceVariant</em>) was defined for this</li>
            </ul>
          </li>
          <li>implement the <em>roots</em> method. 
            <ul>
              <li>The roots for the subscriber are all the projects mapped to 
                the FileSystemProvider. Callbacks were added to FileSystemProvider 
                in order to allow the FileSystemSubscriber to generate change 
                events when projects are mapped and unmapped.</li>
            </ul>
          </li>
        </ul>
        <p>In addition to the subscriber implementation, the get and put operations 
          for the file system provider were modified to update the synchronization 
          state in the ThreeWaySynchronizer. The operations are implemented in 
          the class <em>org.eclipse.team.examples.filesystem.FileSystemOperations</em>.</p>
        <h4>ThreeWaySynchronizer</h4>
        <p>ThreeWaySynchronizer manages the synchronization state between the 
          local workspace and a remote location. It caches and persists the local, 
          base and remote timestamps in order to support the efficient calculation 
          of the synchronization state of a resource. It also fires change notifications 
          to any registered listeners. The ThreeWaySubscriber translates these 
          change events into the proper format to be sent to listeners registered 
          with the subscriber.</p>
        <p>The ThreeWaySynchronizer makes use of Core scheduling rules and locks 
          to ensure thread safety and provide change notification batching.</p>
        <h4>ThreeWayRemoteTree</h4>
        <p>A ThreeWayRemoteTree is a subclass of ResourceVariantTree that is tailored 
          to the ThreeWaySubscriber. It must be overriden by clients to provide 
          the mechanism for fetching the remote state from the server. ResourceVariantTree 
          is discussed in more detail in the next example.</p>
        <h4>CachedResourceVariant</h4>
        <p>A CachedResourceVariant is a partial implementation of IResourceVariant 
          that caches any fetched contents for a period of time (currently 1 hour). 
          This is helpful since the contents may be accessed several times in 
          a short period of time (for example, to determine the synchronization 
          state and display the contents in a compare editor).</p>
        <h3>Building on Top of Existing Workspace Synchronization</h3>
        <p>Many repository providers may already have a mechanism for managing 
          their synchronization state (e.g. if they have exisitng plugins). The 
          <em>ResourceVariantTreeSubscriber</em> and its related classes provide 
          the ability to build on top of an existing synchronization infrastrucutre. 
          This is the superclass of all of the CVS subscribers, for instance.</p>
        <h4>ResourceVariantTreeSubscriber</h4>
        <p>&nbsp;</p>
        <p>subclasses must provide</p>
        <p>base and remote trees</p>
        <p>resource comparator</p>
        <p>roots</p>
        <h4>ResourceVariantTree</h4>
        <p>base and remote tree</p>
        <p>creation of resource variant handles</p>
        <p>Traversal of a resource variant tree</p>
        <p>caches resource variant bytes in a ResourceVariantByteStore</p>
        <p>can use Persistant or Session stores or can provide a custom implementation 
          that access the bytes from some other store. For example the ThreeWayRemoteTree 
          makes use of a byte store implementation that stores the remote bytes 
          in the ThreeWaySynchronizer.</p>
        <p>subclasses must provide code that fetches the current state of the 
          tree from the server and that creates the resource variant handles</p>
        <h4>IResourceVariantComparator</h4>
        <h4>SyncInfo</h4>
        <h3>How Does IRemoteSyncElement Relate to Subsciber</h3>
        <h1>Example: synchronizing with a remote file-system</h1>
        To show how all the APIs comme together we will show you how to create 
        a file system synchronization support using these APIs.<br> <ol>
          <li>Create a subscriber to manage the sync states for the files on the 
            workspace. for now we will use the timestamp at the time the file 
            was copied into the workspace from the remote location</li>
          <li>decide how to refresh the variants<br>
          </li>
          <li>create a participant</li>
          <li>create a set of actions that work on diff nodes<br>
          </li>
        </ol></td>
    </tr>
  </tbody>
</table>
</body>
</html>