2007-09-26 Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: AUGUSTINE, MATTHEW S.
Systems and method for accessing and providing item management functionality with synchronization relationships that share data using a feed that may itself contain synchronization and item information are disclosed. Such systems and methods may enable an endpoint to use item management functionality provided by an item management module to generate or update a feed.
Synchronizing and sharing data between multiple endpoints may be accomplished in a variety of ways. In some implementations, synchronization of data may be implemented, at least in part, by the addition of data, such as synchronization data, to a feed that contains data items. For example, one endpoint might publish a feed that contains data items. Another endpoint, or more than one other endpoint, might subscribe to the feed and be notified when, for example, new items are added or existing items are changed. In addition, a subscribing endpoint might publish its own feed, with the same data as is provided in the original publisher's feed and also with changes or additions made by the subscriber. The original publisher might then subscribe to this second feed. Through these mutual subscriptions, and using synchronization data or information in the shared feeds, changes made by either endpoint may be reflected in the data maintained by both endpoints. Other techniques may also be used, including, for example, procedures for operating with conflicts that might occur, for example, when multiple endpoints change the same item independently.
When data sharing and synchronization is implemented as previously introduced, or when it is implemented in at least some other manners, each endpoint that shares data in a synchronization relationship may want to ensure that a feed that the endpoint publishes conforms to an organization or layout required by the synchronization procedures or techniques. For example, to add a new item to a feed, an endpoint may want to add both information about the item and also add synchronization data associated with the item. If the resulting feed does not conform to one or more particular standards or requirements—perhaps if the correct synchronization data is not added, or if the synchronization data is not formatted or provided in the feed in the correct way, and so on—a variety of problems may occur, including in some cases an inability to share or synchronize the new item. A desire to produce a feed that conforms to a required organization or layout may also be applicable for other types of operations, including modifying existing items, deleting existing items, and so on.
Described herein are various techniques and technologies directed toward the implementation of item management functionality with synchronization relationships that share data using a feed that itself may contain synchronization and item information or data. In at least some cases, rather than generating or updating a feed itself, an endpoint might use item management functionality provided by an item management module to generate or update a feed. In so doing, the endpoint may at least in some cases not need to implement or provide at least some of the item management functionality itself—instead, at least some of the item management functionality may be provided by the item management module.
FIG. 1 illustrates an exemplary system in which item management functionality may be used or implemented.
FIG. 2 illustrates an exemplary generalized operational flow that includes operations that might be performed when communicating and responding to an item management request.
FIG. 3 illustrates one example of a user interface that may be associated with the management of items.
FIG. 4 illustrates an exemplary system that includes an exemplary graphical example of a feed.
FIG. 5 illustrates an exemplary generalized operational flow including various operations that may be performed when modifying an item to include sharing and synchronization data.
FIG. 6 illustrates an exemplary generalized operational flow including various operations that may be performed when performing a local update of an item.
FIG. 7 illustrates an exemplary generalized operational flow that includes various operations that might be performed when merging changes made by another endpoint with the data maintained by a local implementation of an endpoint.
FIG. 8 illustrates an exemplary generalized operational flow that includes operations that might be performed as part of evaluating how a local item might be updated during a merge operation.
FIG. 9 illustrates an exemplary generalized operational flow that includes operations that might be performed when processing conflicts.
FIG. 10 illustrates an exemplary generalized operational flow that includes operations that might be performed as part of resolving conflicts.
FIG. 11 illustrates an exemplary computer device in which the various technologies described herein may be implemented.
Described herein are various techniques and technologies directed toward the implementation of item management functionality with synchronization relationships that share data using a feed that itself may contain synchronization and item information or data. More particularly, in at least some cases, rather than generating or updating a feed itself, an endpoint might use item management functionality provided by an item management module to generate or update a feed. In so doing, the endpoint may at least in some cases not need to implement or provide at least some of the item management functionality itself—instead, at least some of the item management functionality may be provided by the item management module.
In general, in some implementations, synchronization of data may be implemented, at least in part, by the addition of particular data to a feed of data provided using a possibly widely accepted protocol like RSS ("Really Simple Syndication" or "Rich Site Summary"). For example, in an exemplary implementation with a topology that consists of only two endpoints that communicate with each other, one endpoint might publish an RSS feed that contains some type or types of information. In perhaps one example, the feed might include calendar item information represented using a format like iCalendar or hCalendar, or some other format (but could of course contain any data). The other endpoint might subscribe to the feed provided by the first endpoint and be notified when, for example, the first endpoint adds a new calendar item or changes an existing calendar item. In addition, a subscribing endpoint might publish its own feed, with the same data as is provided in the original publisher's feed and also with changes or additions made by the subscriber. The original publisher might then subscribe to this second feed. Through these mutual subscriptions, changes made by either endpoint may be reflected in the data maintained by both endpoints, enabling bi-directional synchronization. Multiple endpoints may participate and share the data by subscribing to at least one of the feeds provided by another endpoint and similarly publishing their own feed.
SSE also defines procedures to be followed by endpoints so that the synchronization information in the feed conforms to a particular organization and, as a result, may be read and used by other endpoints in synchronization relationships. As just one example, SSE specifies particular synchronization information that may exist for an item in an SSE feed. When a new item is created, an endpoint may be responsible for ensuring that the appropriate SSE information is associated with the new item, and that the SSE information is provided in the feed in the correct location, using the correct names, and so on. SSE defines other procedures that also require particular data to be included when, for example, an endpoint modifies an existing item, deletes an existing item, incorporates changes from other endpoints, and so on.
While the synchronization information and organization used in a feed may be specified by something like SSE, the application of such standards may in some cases be non-trivial. For example, to create or modify documents that use SSE, an endpoint may need to include executable instructions for reading or modifying XML data and may need to include executable instructions that update synchronization data by following the rules associated with SSE—including knowing when and how to update version numbers, how to maintain update histories, and so on. Furthermore, there may in some cases be little or no latitude for errors or different interpretations of operations involving the update of synchronization data: if an endpoint modifies the synchronization data in a way that does not conform to the required organization or layout, that endpoint may not be able to share or synchronize data, and may in some cases even prevent or make more difficult the sharing or synchronization of data between other endpoints.
Turning now to FIG. 1, shown therein is an exemplary system 100 in which item management functionality may be used or implemented. The exemplary system 100 contains endpoint A 110, endpoint B 120, endpoint C 130, and endpoint S 140. Each endpoint might represent any number of general-purpose or dedicated computers, including desktop computers, server computers, laptop computers, workstation computers, mobile or cellular telephones, connected personal digital assistants (PDAs), and the like. At least some of the exemplary endpoints are shown as connected using some exemplary communication means 115. Furthermore, at least some of the exemplary endpoints are shown as including an exemplary application, such as the application A 112 and the application B 122. Some endpoints include an exemplary storage module, such as the storage module A 114, the storage module B 124, and the storage module C 134. An exemplary item management module 126 is shown as being associated with endpoint B 120. This description of FIG. 1 may be made with reference to other figures. However, it should be understood that the elements described with reference to FIG. 1 are not intended to be limited to being used with the elements described with reference to other figures. In addition, while the exemplary diagram in FIG. 1 indicates particular elements, in some implementations not all of these elements may exist, and in some implementations additional elements may exist.
An endpoint in a sharing relationship may be a publisher, a subscriber, or both a publisher and a subscriber. A publisher may generally make available a "feed" that contains information associated with the items being shared as part of the sharing relationship. A subscriber may be an endpoint that subscribes to a feed provided by a publisher. In the case where both endpoints in a sharing relationship are publishers and subscribers, each endpoint may make available a feed to which the other endpoint subscribes.
In a sharing relationship where both endpoints publish and subscribe, each endpoint may make "local" changes to items, where a "local" change may be a change made on the particular endpoint for some reason, including changes made by users, by automated processes, and so on. Then, so the items being shared are kept the same on both endpoints, the local change may be published as part of the feed. Because the other endpoint subscribes to the feed, it may "merge" the changes exposed using the feed with its own local store of items. It may also make local changes of its own, which may then be merged or incorporated by the other endpoint.
It is noted that not all endpoints must both publish a feed and subscribe to a corresponding feed. For example, some endpoints may only publish, but not subscribe, to a feed related to some particular set of data. Such endpoints may publish information about local changes made by that endpoint, but may not incorporate changes made by any other endpoint. Any other arrangement of publishing and subscribing actions may be contemplated or implemented depending on the requirements of the particular scenario or situation. Also note that, in some implementations, a particular set of two endpoints might have more than one sharing relationship if they share more than one set of data. In other implementations, a sharing relationship might be defined to include all of the data shared between two endpoints, even if it includes more than a single set or type of data.
For example, endpoint A 110 or endpoint B 120, or some other endpoint including those not shown, might participate in a sharing or synchronization relationship with, say, endpoint S 140. Endpoint A might make, say, an RSS feed available that contains item data and synchronization data. Endpoint S might access this feed, incorporate or merge changes in the feed into its own store of items, and in turn make its own feed available. Endpoint A might then subscribe to the feed provided by endpoint S and merge changes made by endpoint S. As a further example, in other cases, one endpoint may act on behalf of another endpoint by, for example, providing or accessing feeds. For example, endpoint A and endpoint S might participate in a sharing relationship, but endpoint S might actually access or be provided a feed from endpoint B, instead of from endpoint A.
It should further be noted that while in some implementations a sharing relationship might exist between two endpoints, it is also possible for a particular set of items to be shared and synchronized with any number of endpoints. This may be accomplished through a variety of arrangements or topologies of endpoints. As just one example, a set of some number of endpoints might synchronize with a particular endpoint, and that particular endpoint might then synchronize with one or more additional endpoints that do not synchronize information directly with the original set of endpoints. In at least some of such cases, or other cases, information may be synchronized throughout the entire "mesh" of synchronizing endpoints.
Endpoint A 110 and endpoint S 140 are shown in the system 100 as being connected by an exemplary communications means 115. Generally, endpoints may be connected by any means by which data may be transmitted, including any type of network or any other kind of transfer, including the transfer of physical media, like a compact disc (CD) or flash memory drive. Furthermore, while in the system 100 some endpoints are not shown as connected by the communication means 115, in some implementations additional or all endpoints may be connected by such communications means, or by other communications means. Endpoints might also be connected directly.
Any endpoint may subscribe to and publish a variety of feeds, and the feeds may be represented using different formats, as introduced previously. Furthermore, items obtained from a feed that is represented using a particular format need not be published or further distributed using a feed or feeds that use that same format—items may be published in any format supported or understood by the publisher. For example, an endpoint might subscribe to one feed that uses RSS and another feed that uses Atom. That same endpoint may then publish the same set of data, or any other set of data, using RSS, Atom, or any other type of feed format, independent of how the data was originally obtained or represented.
In some implementations, including those that may not use functionality like that provided by the exemplary item management module 126, an endpoint in a sharing or synchronization relationship might itself generate or update a feed used in a synchronization relationship. For example, a user might use application A 112 to modify some data that is in turn being shared and synchronized by endpoint A, perhaps with endpoint S. In order for the change made by the user to be made available to endpoint S, endpoint A might need to update the feed with the changed item information, as well as with changed synchronization information. In an implementation that uses SSE, the synchronization information in the feed might be updated, for example, by following a procedure such as that described below with reference to FIG. 6. In such an example, or in other examples, endpoint A might update an XML document that embodies the feed by, among other things, updating a "version" attribute with a new version number, by modifying an update history associated with the item by creating new XML elements, and so on.
However, in the same or other implementations, endpoint A may not itself update the feed with which it shares information with some other endpoint. Instead, it may use functionality provided by, for example, an item management module, such as the exemplary item management module 126. To update an item in the feed, endpoint A might communicate, for example, an "update item" request to the item management module. Such a request might include information like an identification of the feed to be updated and the item information to be modified. The item management module might then update the feed appropriately, conforming to the organization and rules defined for the synchronization techniques in use. Endpoint A might then retrieve or be provided with the updated feed, and it might then make the feed available to other endpoints with which it has sharing relationships. In such an implementation, endpoint A may participate in a sharing relationship without necessarily having the capability of modifying, updating, or generating its own feeds of data. Instead, such operations may be performed by, for example, an item management module, on behalf of some other endpoint, like endpoint A. In at least some implementations, an item management module may be associated with at least some operations described below in more detail with reference to FIG. 2, and described especially with reference to, for example, operation 230.
The information that is shared between endpoints as part of a sharing relationship may be stored in a variety of manners and locations. In at least one implementation, an endpoint that uses an item management module, such as endpoint A 110, might store the shared data locally or in some location that is not associated with the item management module. Such storage may in some cases be represented by the storage module A 114, which might be one or more disk drives or magnetic or other storage devices, or any other mechanism by which data may be stored. Such other mechanisms may include storage devices that are not part of the same endpoint as endpoint A and that may be accessed, for example, using a network or other communication means.
In some implementations, an endpoint might store data that is shared using something like a database, or other storage mechanism, and might generate a feed dynamically or at particular times. In the same or other implementations, an endpoint might store the feed itself (perhaps by storing an XML file in the case of an RSS feed, or the like).
When an endpoint such as endpoint A 110 stores shared data using an associated storage module, like storage module A 114, or in other implementations, the endpoint may communicate the data to the item management module. For example, when endpoint A communicates an "update item" request to the item management module, endpoint A might also include an XML feed document that embodies the feed in which the item update should be performed. In such an example, the item management module might perform the item update and return or make available an updated feed document. In another example, endpoint A might communicate a reference to the feed, which the item management module might use to retrieve or access the feed.
In yet another example, an endpoint such as endpoint A might not store the shared data or feed in a storage module associated with the endpoint. Instead, the endpoint might rely on storage provided by some other endpoint including, in some examples, by an endpoint that also provides item management functionality. For example, endpoint B might include storage module B 124, which might store shared data, perhaps in the form of XML feed documents, or in some other form (such as rows in a database, files in a file system, and so on). In such an implementation, an endpoint that wants to use the item management module might not need to provide the data on which the item management module operates —instead, the endpoint might only need to provide, for example, some way for the item management module to identify the data on which to operate. For example, endpoint A might provide an identifier—such as, perhaps, an ID value—that is associated with a data set or feed stored in storage module B 124. In such an example, the item management module 126 might operate on the data locally, after which endpoint A might retrieve an updated feed, for example, from endpoint B.
In the same or other implementations, endpoint B might itself make a feed available for sharing and so take part in a synchronization relationship with another endpoint, such as endpoint S 140. Such a feed might be accessible at, for example, a feed URL associated with endpoint B. In such cases, an identifier provided to the item management module by another endpoint, such as by endpoint A, might be the feed URL itself. The item management module might use this feed URL to identify, and perhaps also to access the feed and perform the requested operation.
In the same or other implementations, a feed might be provided by yet another endpoint, such as by endpoint C 130. In this or other examples, endpoint C might store the feed, or data used to generate the feed, in a storage module C 134. In such an arrangement, for example, endpoint C might be part of a sharing relationship with, say, endpoint S 140. That is, endpoint S might retrieve a feed from endpoint C, merge changes from the feed into a store maintained by endpoint S, and so on. Although not required, endpoint C might in some implementations be an "SSE Service" or the like, in that it may accept feeds that contain changes from other endpoints, might incorporate those changes into its local data store, and might then make an updated feed available to subscribing endpoints, such as, perhaps, endpoint S. In some implementations, endpoint C might accept, for example, an HTTP POST request to one URL per feed, where the POST request includes a feed with changes; merge the changes in the feed into its own data; and then make an updated feed available by responding to HTTP GET requests communicated to the same URL.
In such an implementation, an endpoint that has the capability to generate its own feed might be interact with endpoint C 130 directly by submitting modified feeds and retrieving updated feeds. However, the same or other endpoints might also interact with endpoint C through an item management module, such as the exemplary item management module 126. For example, endpoint A might communicate an "update item" request to the item management module, as before, but might identify, directly or indirectly, a feed or data set managed by endpoint C. Rather than updating data locally, the item management module might itself generate a new feed and communicate that feed to endpoint C—perhaps using an HTTP POST, as previously described, or through some other mechanism. The item management module may then, at some subsequent time, retrieve or access an updated feed provided by endpoint C, and may further in some cases provide such a feed, or data from such a feed, to endpoint A. In doing so, the item management module 126, and endpoint B 120, may in some cases be considered to act as an intermediary to or proxy for a communication between endpoint A and endpoint C.
It should be noted that while in at least some of the previous examples, changes were explained as being made by an application on an endpoint that does not include an item management module, such as application A 112, in the same or other implementations, an application might exist on any other endpoint. In some implementations, even the endpoint that includes an item management module might also include one or more applications, such as application B 122.
Turning now to FIG. 2, shown therein is an exemplary generalized operational flow 200 that includes operations that might be performed when communicating and responding to an item management request. In this context, and as will be described in more detail below, a request might be associated with an item management action such as, for example and without limitation, retrieving a listing of existing items, creating a new item, retrieving information associated with an existing item, updating an existing item, and deleting an existing item. This description of FIG. 2 may be made with reference to other figures. However, it should be understood that the operational flow described with reference to FIG. 2 is not intended to be limited to being used with the elements described with reference to these other figures. In addition, while the exemplary operational flow of FIG. 2 indicates a particular order of execution, in one or more alternative embodiments the operations may be ordered differently. Furthermore, while the exemplary operational flow contains multiple steps, it should be recognized that in some implementations at least some of these operations may be combined or executed contemporaneously.
In some implementations, the operations in the "item management client" column—operations 210, 215, 220, 240, and 245—may be performed on an endpoint that uses item management functionality. For example, such operations might be performed on an endpoint like endpoint A 110, described previously with reference to FIG. 1. In at least some implementations, a user interface associated with at least one of these operations may have at least some characteristics associated with the exemplary user interface described below with reference to FIG. 3. In the same or other implementations, the operations in the "item management provider" column—operations 225, 230, and 235—may be performed on an endpoint that includes an item management module. For example, such operations might be performed on an endpoint such as endpoint B 120, also previously described with reference to FIG. 1. In some implementations, both sets of operations may be performed on the same endpoint, while in other implementations, particular operations may be performed on a variety of different endpoints, including on more than two endpoints.
In an exemplary implementation of operation 210, a data set to be managed may be identified. The data set may be considered to comprise or be associated with the items that are shared as part of a synchronization relationship. For example, in an implementation where a synchronization relationship exists that synchronizes contact information, the data set might comprise a set of contacts. In other implementations, the data set might comprise any type or amount of data. In at least some implementations, the data set may be associated with a feed used in a synchronization relationship, where the feed includes synchronization data and item data. In some implementations, such a feed may be the same as or similar to the exemplary feed described below, for example and without limitation, with reference to FIG. 4.
The data set may be identified in a variety of ways depending on characteristics such as, for example, the location or locations in which the data set is stored, one or more properties of the network—like network topology or available bandwidth, and so on. For example, in at least some implementations, a data set may be identified by some reference to a feed used as part of the synchronization relationship itself. The reference might be embodied, in some implementations, as a URL. Such a feed might be managed or accessible through a variety of endpoints, including in arrangements that have been previously described with reference to FIG. 1. For example, in some cases a feed might be provided or accessible through the endpoint on which operation 210 is implemented; in other implementations a feed might be accessible through another endpoint—like through endpoint B or endpoint C; and so on. In other implementations, some other identifying characteristic or characteristics of a data set or feed might be used to identify the data set to manage. For example, an alphanumeric identifier, such as possibly a GUID ("globally unique identifier") might be used in some implementations to identify or map to a particular set of data. In yet other implementations, a data set might be identified through an embodiment of the data in the data set itself. For example, rather than specifying the URL of a feed, a feed document itself—perhaps in XML or some other format—might be used to identify the data set.
In at least some implementations, all or part of operation 210, as well as perhaps other operations, may be accessible to executable code on an endpoint through one or more application programming interfaces (APIs). As just one example, an endpoint might implement all or part of operation 210 and identify a data set to manage by calling a function or method provided by some API. In some cases, the implementation of the API might then interact with the item management module in one or more of a variety of fashions. The endpoint might also perform other operations, such as identifying an item management action, and so on, using the same or other API.
In some implementations of operation 215, an item management action may be identified. In some implementations such item management actions may include, for example and without limitation, retrieving a listing of existing items, creating a new item, retrieving information associated with an existing item, updating an existing item, and deleting an existing item. In the same or other implementations, additional or other item management actions may be identified in this operation.
As part of operation 215, or as part of other operations, any information or data relevant to the identified item management action may be provided. For example, when updating an existing item, such information might include an identification of the item to be updated as well as the data to be used during the update.
In an exemplary implementation of operation 220, an item management request may be communicated to an item management module. The item management request may include a variety of information, including an identification of a data set to manage and an identification of an item management action to be performed by the item management module. In some implementations, the former may have been identified as part of operation 210 and the latter may have been identified as part of operation 215, while in other implementations such data may have been specified or identified in one or more other fashions or operations.
For example, in at least some implementations where the item management action is associated with one or more items that have item data and synchronization data, at least some of the synchronization data may be communicated or identified for use when implementing the item management action. In one specific example, and without limitation, suppose an item—that is perhaps associated with item data and sync data as described below with reference to FIG. 4—is identified as being associated with an item management action that includes updating the item. In some implementations, an item management request might also include the sync data associated with the item. Such sync data might then be used as part of implementing the request—for example, the item management module might be able to use the sync data as part of determining if the requested update would cause a conflict, or for other purposes.
An item management provider or, in some cases an item management module, may provide one or more "interfaces" or means for accessing the functionality associated with the item management provider. Depending on, among other things, the interface or interfaces used in an implementation of operation 220, the specific form of or data that may be communicated may be different.
In another example, and in contrast to a programmatic interface as introduced previously, an item management provider may provide an interface that returns some kind or portion of a user interface representation. In some implementations, such a user interface representation may then be displayed or otherwise used by the endpoint that initiates the request. For example, in some cases an endpoint might communicate an item management request as, say, an HTTP GET request to a particular URL, and receive in return an HTML page that includes a user interface appropriate to the requested item management action. For example, if the request is to list existing items, a reply might include an HTML page with markup that, when rendered, displays the items. In other implementations, a user interface representation may be communicated in any of a variety of formats, as long as the user interface representation includes data that, when rendered, may display a user interface. In contrast to at least some programmatic interfaces, where data returned may need to be processed in some form before it is displayed, a user interface representation may generally be rendered by, for example, a display processing module or rendering module.
In an exemplary implementation of operation 225, an item management module may receive an item management request from an endpoint. The manner in which this operation is implemented may vary depending on characteristics such as the interface used by the requesting endpoint, and so on. The received request may in some cases include one or both of identification of an item management action and some type of identification of a data set to manage and on which the item management action may be performed. This information may be identified and provided in a variety of ways, including in manners such as those described previously with reference to operation 210, operation 215, and operation 220, and may in other implementations be identified or provided in different ways.
In at least one exemplary implementation of operation 230, the requested item management action may be performed. The manner in which this operation may be implemented, and the resulting operations that may be executed in an implementation of operation 230, may vary depending on characteristics such as the requested action, the manner in which the data set is identified and accessed, the way in which the request was communicated and in which the response may be communicated, and so on.
For example, if the requested item management action is to retrieve a list of the items in the data set or to retrieve specific item information for one or more items in the data set, an implementation of this operation might query or otherwise access information about the identified data set. In one implementation, such an operation might be performed by, for example, querying a database; in another example, the operation might be performed by retrieving information from a file, including perhaps an XML representation of the data set; and so on. Furthermore, in some implementations, the information about the data set might reside or be associated with the endpoint on which, for example, this operation is being executed, while in other implementations the data may be stored or accessible through some other endpoint. Just one example where data may be available elsewhere is the relationship described previously with reference especially to endpoint B 120 and endpoint C 130, both of FIG. 1. In such an example, endpoint B might access a data set managed by endpoint C through, for example, HTTP GET and HTTP POST requests that exchange feed documents.
As another example of how a requested item management action might be performed, if the requested action is to update or add to the data set, the item management module might perform the appropriate operations on the data set. This might involve updating information in database, updating one or more files, communicating an HTTP POST request with an updated feed, and so on. Such operations might be performed when, for example, the requested item management operation is to create a new item, update an existing item, or to delete an existing item.
In at least some implementations, part of performing the requested item management operation may include executing operations defined or specified by one or more synchronization techniques related to a feed associated with the identified data set, and used as part of a synchronization relationship. For example, when the item management action is to create a new item, in some implementations at least some of the operations described below with reference to FIG. 5 may be performed, including defining a new item data element and a new sync data element in a feed. Similarly, when the requested item management action is to update an existing item or in some cases to delete an existing item, at least some of the operations described below with reference to FIG. 6 may be performed, including operations like incrementing version values, modifying update history, and so on. In at least some of such cases, or in other cases, part of performing the requested item management operation may include updating or modifying synchronization information, or sync data, associated with one or more of the items, including items that are associated with the item management operation, or other items.
In an exemplary implementation of operation 235, an item management response may be communicated from the endpoint associated with the item management module. As before with the request, the manner in which the response may be communicated may vary widely depending on a variety of characteristics including the nature of the request, and so on. For example, in some implementations, the response might comprise an HTTP response to a previous HTTP request, while in other implementations, the response might comprise a response to some subsequent HTTP request, or might comprise some communication initiated by the endpoint on which the item management action was performed, or might comprise some other type of response.
In an exemplary implementation of operation 240, the endpoint that initiated the item management request may obtain an item management response, again in a variety of manners and fashions depending on a variety of characteristics and factors, as introduced previously.
Turning now to FIG. 3, shown therein is one example of a user interface 300 that may be associated with the management of items. This description of FIG. 3 may be made with reference to other figures. However, it should be understood that the elements described with reference to FIG. 3 are not intended to be limited to being used with the elements described with reference to other figures. In addition, while the exemplary diagram in FIG. 3 indicates particular elements, in some implementations not all of these elements may exist, and in some implementations additional elements may exist. Furthermore, it should be understood that the exemplary graphical representations of the systems and user interfaces shown in FIG. 3 are provided only for purposes of discussion, and in no way should be construed as limiting the scope of the techniques described herein to any particular graphical or other representation. Furthermore, the user interface is exemplary and may be implemented in a variety of ways, using a variety of technologies, with a variety of differences from the exemplary user interface, and so on, without departing from the elements of the user interface as described herein.
The exemplary user interface 300 demonstrates just one manner in which an endpoint might display and enable editing of item information. In some implementations, for example, a user interface like user interface 300 might be displayed as part of or as a result of processing an item management response, as was previously described with reference to operation 245 of FIG. 2. In the same or other implementations, the user interface 300 might enable a user to perform operations such as identifying an item management action (as in operation 215), and initiating the communication of an item management request (as in operation 220), perhaps by clicking or pressing a button such as the save button 360. In other cases and implementations, a user interface like user interface 300 might be displayed at other times, for other reasons, and may enable other functionality.
As shown, the exemplary user interface 300 comprises labels 310, 320, 330, 340, and 350; fields 312, 322, 332, 342, and 352; and a save button 360 and cancel button 370.
The labels, as shown, include text such as "title", "description", and so on, but could contain any text, graphic, or other user interface element or elements. Generally in this example, a label may be associated with one or more fields. For example, the label 310 may be associated with the field 312. In this example, and in at least some implementations, at least some of the labels may correspond to, for example, pieces of information associated with a data set or with a feed used in a synchronization relationship. For example, the label 310, with the text "title", might be associated in some implementations with a "title" element (which might in some cases in turn be a child of an "item" element). The associated field, which is field 312 in this specific example, might then display the value of the associated element, or might display some other information or data that is somehow associated with the piece of information or label.
In examples where the feed uses a standard such as RSS or Atom, at least some of the displayed labels and fields may be associated with data that is generally accepted to be part of, for example, an RSS or Atom feed document. Two examples of such data in the case of RSS feeds are "title" and "description" data, because RSS feeds typically include items that have "title" and "description" elements. Feeds may also contain other additional data or elements. In some implementations, it may not be possible for an endpoint to treat this other additional data with any specific processing—in such a case, for example, the endpoint might display such additional data in a general field, such as the field 352 associated with the generic label 350 that in this example contains the text "other data".
In some implementations, a data set or feed may be associated with information that provides organizing or schema data about the data set or feed. Such schema information may be used in some implementations in various ways, including as part of interpreting the "other data" in a feed and, therefore, as part of generating or building a user interface representation that may contain additional information, or in the implementation of an API that might be used by an endpoint.
As just one example, suppose that the information communicated to a requesting endpoint as part of an item management response, or the information in a feed document itself or accessible through some means, contains additional schema information that defines data such as the data type of elements in the feed, a user interface label for one or more elements in the feed, and so on. In such a case, rather than just displaying, for example, standard labels such as "title" and "description" and displaying all other data in a generic field like field 352, an endpoint might interpret the provided schema information and use it to identify additional information about the data. Such additional information might then, for example, be displayed with one or more dedicated labels or fields, or used in a variety of other ways. In the exemplary user interface 300, both the label 330, with the text "Property A", and the label 340, with the text "Property B", and both associated fields 332 and 342, might have been identified using schema or other organizing information associated with the data set or feed in some fashion. Using this information, executable code associated with the user interface may have been able to determine, for example, that a user interface label for a particular piece of data could use the text "Property A", may have been able to determine how to retrieve the associated data from the data in the feed (in this case, the associated data might be "This is a sample value for Prop A."), and so on.
The same schema information may be used as part of providing an API to, for example, an endpoint that receives item management responses. Instead of requiring that the endpoint interpret or parse, for example, all of the "other data" on its own, schema or organizing information may be used in the implementation of an API so that code that might execute on or be associated with an endpoint might use the API to access specific additional fields, such as "Property A" and "Property B", by name, for example.
In at least some implementations, particular user interface elements in an exemplary user interface like the user interface 300 may be associated with the initiation of, for example, additional item management requests. In one implementation, for example, the save button 360 might initiate an item management request to update the displayed item with any changes that have been made using the displayed fields. In the case where at least part of the user interface 300 is communicated as part of an item management response—using HTML, for example—the link between the exemplary save button and the initiation of another item management request might be communicated as part of an initial item management response. That is, for example, the HTML markup that creates the button may be communicated with an associated URL that, when communicated in an HTTP request, comprises at least part of an item management request. In other implementations, including at least some where an initial item management response does not contain a user interface representation, a user interface element like the save button might be created as part of processing programmatic data.
As has been described previously, various operations performed as part of sharing items may be implemented using, among other techniques, one or more extensions to existing feed protocols, including SSE. Some of the following description provides more information about SSE, including exemplary feeds and operations such as additions, modifications, and merges.
Turning now to FIG. 4, shown therein is an exemplary system 400 that includes a graphical example of a feed 410. A feed 410 might contain a header 420 as well as some number of items including, in some examples, item 1 440, item 2 480, and item N 490. Each item might contain sync data 450 and item data 460. This description of FIG. 4 may be made with reference to other figures. However, it should be understood that the elements described with reference to FIG. 4 are not intended to be limited to being used with the elements described with reference to other figures. In addition, while the exemplary diagram in FIG. 4 indicates particular elements, in some implementations not all of these elements may exist, and in some implementations additional elements may exist.
Regardless of the format used by the feed, an exemplary feed 410 may in some cases contain a header with header information that may be general to the entire feed, such as the exemplary header 420. In the case where the feed uses RSS, the header 420 might contain some or all of some standard RSS header elements, such as the "rss" element, the "channel" element, the "title" element, the "description" element, and so on.
The header 420 might contain header data like that represented in this example by the "sharing" element including some or all of the "since", "until", and "version" attributes, or the like.
Such data might include a value associated with an attribute like "link", which might represent a URL or other reference to a related feed. The data might also include a value associated with an attribute like "title", which might contain a name or description of the related feed.
Item data 460 may generally comprise information related to the item itself. In the previous example, the item data 460 might include the RSS "title" and "description" elements. In another example, if a feed contains an item for each of a specified set of contacts, the item data 460 might generally contain information about a particular contact's name, address, phone number(s), and so on. The item data information might be represented in any of a wide variety of formats. In the case of contact information, for example, the item information might be represented using the hCard standard, the vCard standard, or any other format that contains contact information. It is noted that the item data may be stored in any format and is not limited to, for example, XML, XHTML, or any other standardized method for representing information. If a feed is associated with information typically represented in binary form, like audio data or image data, the item data might include such binary information, and so on. The item data may also be stored outside of the feed. In such an implementation, the feed may reference the item data, perhaps using an element like the RSS "enclosure" element.
Sync data 450 generally comprises information associated with the sharing and synchronization of the associated item data. In some implementations this might include data represented, for example, using a "sync" element that might have some or all of the "id", "version", "deleted", and "noconflicts" attributes, or the like, as well as additional attributes. The sync data 450 might also include elements that are, in some implementations, children of a "sync" element, including, for example and without limitation, "history", "update" (which might be a child of a "history" element), "conflicts", and "resolvedconflicts", and the like, as well as additional elements. In some implementations, items that include a valid sync data element 450, or the like, may be considered to be "configured for sharing," in that they may contain information used when sharing the item between multiple endpoints.
Such data might include a value associated with an attribute like "id", which might represent the identifier for the particular item. The value of this attribute may in some implementations be unique within a feed and might also be globally unique across feeds if an item is being shared or synchronized. In some implementations, the value of this attribute might be assigned by the creator of the item, and should not be changed by subsequent publishers.
In addition to attributes that might be used with a "sync" element, or the like, some implementations may maintain a chronological change history for an element, possibly through the use of an element that is a child of the "sync" element, and that might, in some implementations, have the name "history". In some implementations, such an element might have some or all of "when" and "by" attributes, or the like, as well as additional attributes. A "history" element might also, in some implementations, sometimes have one or more "update" elements as children, as well as additional elements. An exemplary "update" element is described in more detail below.
In some implementations, some parts of an item's change history might be maintained through the use of an "update" element, or the like, as part of the item's sync data 460. In some of these implementations, each "update" element might represent a distinct update operation applied to the associated item. In some implementations a new "update" element might be created each time the item is updated.
Another set of elements that might be part of an item's sync data 450 might be a conflict collection and a resolved conflict collection, perhaps represented using a "conflicts" element and a "resolvedconflicts" element, or the like. Both of these elements might be used, for example, as part of a conflict preservation implementation. Such an implementation might preserve, for example, the "losing" change when two changes conflict. Some examples of conflict preservation implementations are described below, for example, with reference to FIG. 7, FIG. 8, FIG. 9, and FIG. 10.
Turning now to FIG. 5, shown therein is an exemplary generalized operational flow 500 including various operations that may be performed when modifying an item to include sharing and synchronization data. The following description of FIG. 5 may be made with reference to other figures. However, it should be understood that the operational flow described with reference to FIG. 5 is not intended to be limited to being used with the elements described with reference to these other figures. In addition, while the exemplary operational flow of FIG. 5 indicates a particular order of execution, in one or more alternative embodiments the operations may be ordered differently. Furthermore, while the exemplary operational flow contains multiple steps, it should be recognized that in some implementations at least some of these operations may be combined or executed contemporaneously.
The operations described in the exemplary operational flow 500 may generally be performed when an item that has not previously been configured for sharing or synchronization is to be shared. One example of when such operations might be performed is when a new item is created as a result of a local user operation. For example, if a user is synchronizing her contact information and creates a new contact, the operations described with reference to FIG. 5 might be performed so that the contact contains the minimum set of sharing information necessary for the sharing of that contact. Another example of when such operations might be performed might be when a set of items that already exists but that is not configured for synchronization is extended to support sharing and synchronization.
In one example of operation 510, new sync data may be defined. This new sync data might include, for example, a unique identifier and an initial version value. In some cases the initial version value may be a starting version of "1". Further, in implementations that, for example, generate a feed that is represented using XML, this operation might result in the creation of a new "sync" element, or the like, or the definition or creation of data that ultimately results in the creation or generation of a "sync" element when a feed is generated. In such implementations, or in other implementations, the unique identifier data might be associated with an "id" attribute and the version information might be associated with a "version" attribute.
In an exemplary implementation of operation 515, an update history may be created. The newly created update history may contain information about this initial update, perhaps specified using one or both of values that define when the information was defined and by whom the information was defined. In implementations that, for example, generate a feed that is represented using XML, this operation might result in the creation of a new "history" element, or the like, or the definition or creation of data that ultimately results in the generation of a "history" element when a feed is generated. In such implementations, or in other implementations, the time when this information was defined might be associated with a "when" attribute and the entity that defined this information might be associated with a "by" attribute.
In some implementations, the information defined by the operations of the exemplary operational flow 500 might be considered to form at least part of the sync data 450 described previously with reference to FIG. 4. In the same or other implementations, the item data that existed before the execution of the exemplary operational flow 500 might be considered to form at least part of the item data 460 also described previously with reference to FIG. 4.
Turning now to FIG. 6, shown therein is an exemplary generalized operational flow 600 including various operations that may be performed when performing a local update of an item. The following description of FIG. 6 may be made with reference to other figures. However, it should be understood that the operational flow described with reference to FIG. 6 is not intended to be limited to being used with the elements described with reference to these other figures. In addition, while the exemplary operational flow of FIG. 6 indicates a particular order of execution, in one or more alternative embodiments the operations may be ordered differently. Furthermore, while the exemplary operational flow contains multiple steps, it should be recognized that in some implementations at least some of these operations may be combined or executed contemporaneously.
A local update, as performed by the operations of the exemplary operational flow 600, may be defined as an update that is performed outside of a merge operation. Such a local update may include both the modification of an item—for example, this might include the modification of a contact's address or phone number in a contact item—as well as the deletion of an item. For example, when a user uses an application to modify data that is ultimately shared as part of a feed, at some point a local update may be made to the data in the feed associated with the change made by the user.
In an exemplary implementation of operation 610 the version data associated with the item may be incremented, for example, by one. In implementations that, for example, generate a feed that is represented using XML, this operation might result in a change to the value associated with a "version" attribute. If the previous value of the version attribute was "1" a new value might be "2", and so on.
In one implementation of operation 615, the update history of the item might be modified so as to capture information about when this particular modification takes place and also, in some implementations, to maintain at least some information about previous modifications. One possible implementation of this operation might involve first creating a new "update" element, or the like, as the first member of the existing update history (in doing so, any previously existing update information might be moved down in order). Note that, as has been previously stated, while this operation, and others, may be described in some cases in the context of concepts related to XML including, for example, elements and attributes, these descriptions are in no way limiting to an implementation that only uses or results in XML data. For example, in some implementations an update history, including the information described as residing, in some implementations, in "history" and "update" elements, might be created and maintained in memory, using database records or other data structures, and the like. In any implementations, the relevant information may never be stored, persisted, or communicated as XML. Some of the descriptions provided herein use XML concepts only for ease of explanation.
To set the values of the "when" (modification time) and "by" (modifying entity) attributes of the new "update" element, operation 615 might copy the corresponding data from the current "history" element. In doing so, data about the most recent previous modification—which may have been previously recorded with "when" and "by" values in the "history" element—may now be saved in the new "update" element, and so may not be lost if the data associated with the "history" element is updated.
In some implementations, operation 615 may truncate the update history by deleting some or all of the "update" elements. In implementations that truncate the update history, the "update" elements may generally be deleted in reverse order of their creation so that older update history is deleted before newer update history.
Finally, operation 615 might set one or both of the "when" (again, modification time) and "by" (again, modifying entity) attributes of the top-level "history" element to the current time and entity making this modification, respectively.
In this example, the execution of the exemplary operational flow 600 three different times has resulted in the creation of three "update" elements that represent the time at which the modification took place and the entity that made the modification.
Turning now to FIG. 7, shown therein is an exemplary generalized operational flow 700 that includes various operations that might be performed when merging changes made by another endpoint with the data maintained by a local implementation of an endpoint. The following description of FIG. 7 may be made with reference to other figures. However, it should be understood that the operational flow described with reference to FIG. 7 is not intended to be limited to being used with the elements described with reference to these other figures. In addition, while the exemplary operational flow of FIG. 7 indicates a particular order of execution, in one or more alternative embodiments the operations may be ordered differently. Furthermore, while the exemplary operational flow contains multiple steps, it should be recognized that in some implementations at least some of these operations may be combined or executed contemporaneously.
In an exemplary implementation of operation 710, a foreign feed that contains information about the items synchronized between two endpoints may be accessed. In some embodiments, a foreign feed may be made up of items that each may contain item data and sync data, for example, perhaps as further described previously with reference to FIG. 4. In some implementations, the foreign feed may be the feed provided by one endpoint, such as, in particular implementations, by endpoint A 110, endpoint B 120, endpoint C 130, or endpoint S 140, all of FIG. 1, when a second endpoint in a sharing relationship obtains that feed and merges its changes into the second endpoint's local data.
In general, a foreign feed may be provided in some fashion by another endpoint. For example, the operation of accessing the foreign feed may in some implementations involve using a network to physically retrieve a file or files that contain the foreign feed. Because the mechanism by which the foreign feed is accessed or transmitted may be irrelevant to the operation of the steps illustrated with reference to FIG. 7, this step may also encompass any other means by which a foreign feed may be accessed, including manual transfer of data using some other form of storage including a CD, a flash drive, a physical printout of data on paper, and so on. A particular foreign feed may not necessarily contain all of the items synchronized by a particular endpoint—for example, an endpoint may synchronize with multiple foreign feeds, each which may contain the same or a different set of items.
It should be noted that while some of the preceding and following description may refer to the foreign feed as, for example, an XML document that contains item and sharing information perhaps like that described elsewhere in this specification, the foreign feed is not so limited. For example, the foreign feed may not necessarily always be provided as an XML document. Any feed provided by another endpoint that contains item and sharing information may possibly be accessed or used as described in this operation and the operational flow 700.
In at least one implementation of operation 715, it may be determined if the foreign feed contains any foreign items that have not yet been processed. In this context, the term "foreign item" may refer to an item defined by the foreign feed, in contrast to a "local item," which may refer to an item stored or managed by the entity that accesses the foreign feed, including, in some implementations, the entity or entities that execute the operational flow 700. If there are no remaining foreign items to process, the operational flow ends. If the foreign feed contains at least one item that has not yet been processed, the exemplary operational flow proceeds to operation 720.
In an exemplary implementation of operation 720, the next foreign item is retrieved from or identified using the foreign feed. For example, if the foreign feed is associated with five foreign items, the first time operation 720 is executed, one of these items may be retrieved. The next time operation 720 is executed, another of these items may be retrieved, and so on. This may continue until all foreign items have been retrieved, at which point operation 715 stops any further retrieval.
In at least one implementation of operation 725, it is determined if the current foreign item—that is, the foreign item retrieved in the most recent execution of operation 720—is a new item that the endpoint performing the exemplary operational flow 700 has not yet evaluated. In some implementations, this operation may be performed by determining if a data store that contains local items and is managed or accessible from the local endpoint contains an item that has the same unique identifier as the current foreign item. If no such local item exists, the foreign item may be determined to be new, and the operational flow may proceed to operation 730. If the local data store contains an item with the same unique identifier as the foreign item, the foreign item may not be considered new, and the operational flow may proceed to operation 735.
If the foreign item is new, the operational flow may proceed to operation 730 where, in an exemplary implementation, data from the foreign item may be used to create a corresponding local item. The implementation of this operation may vary according to different factors including how, for example, local items are stored. In some implementations, this operation may be performed by creating a new database record or records, a new data structure or data structures, and so on, and setting the rows, fields, or the like by copying information from the foreign item. In other implementations, this operation may be performed by copying the information from the foreign item into a feed document maintained locally, and so on.
If the foreign item is not new, the operational flow may proceed to operation 735 where, in at least some implementations, data from the foreign item is used to evaluate if and how the corresponding local item should be updated. For example, data from the foreign item may be determined to be more recent than data from the local item, and so may in some cases overwrite the corresponding data in the local item. A number of other operations may occur as part of the evaluate local item update operation. An exemplary implementation of these other operations is described in more detail below, with reference to FIG. 8. It should be noted that, in at least some implementations, data that is overwritten may need to be saved, at least until the remaining operations that relate to this foreign item are performed. For example, an operation related to processing conflicts may use some of the data that might be overwritten as part of operation 735.
In an exemplary implementation of operation 740, it may be determined if it is necessary to process conflicts associated with the foreign item and the local item. If no conflict processing is needed, the operational flow may proceed to operation 715. If conflict processing is required, the operational flow may proceed to operation 745. This determination may be made in a variety of ways, including by, for example, determining if the foreign item, the local item, or both items contain a flag or some other data that indicates if conflicts should be or should not be processed. In some implementations, such a flag might be the "noconflicts" attribute described previously, for example with reference to FIG. 4. In these implementations, if the "noconflicts" attribute exists and is set to "true", no conflict processing may be necessary.
If conflict processing is indicated, the operational flow may proceed to operation 745, where, in an exemplary implementation, potential conflicts between the foreign item and the local item may be processed. The steps executed during conflict processing may vary in different implementations and may include one or both of a conflict detection operation and a conflict preservation option. One implementation of conflict processing operations, such as these, is described in more detail below, with reference to FIG. 9.
Turning now to FIG. 8, shown therein is an exemplary generalized operational flow 800 that includes operations that might be performed as part of evaluating how a local item might be updated during a merge operation. In some implementations, the steps described in FIG. 8 may be used as all or part of an implementation of operation 735 described previously with reference to FIG. 7. This description of FIG. 8 may be made with reference to other figures. However, it should be understood that the operational flow described with reference to FIG. 8 is not intended to be limited to being used with the elements described with reference to these other figures. In addition, while the exemplary operational flow of FIG. 8 indicates a particular order of execution, in one or more alternative embodiments the operations may be ordered differently. Furthermore, while the exemplary operational flow contains multiple steps, it should be recognized that in some implementations at least some of these operations may be combined or executed contemporaneously.
In an exemplary implementation of operation 810, a "winning item" and "losing item" may be determined from two items presented. For example, when the operations in the operational flow 800 are used in the context of the merge operational flow 700 described previously with reference to FIG. 7, the two items presented may comprise the foreign item and the local item identified as part of the merge operational flow 700. One of these items may be selected to be the winning item, which in some implementations is the item that is determined to have precedence, for some reason or reasons, and the other item may be selected to be the losing item. Furthermore, in some cases neither item may be determined to be the winning item or the losing item.
In some implementations, the determination of the winning item and the losing item may be made by comparing data associated with both items. For example, the winning item and losing item may be determined by a comparison of the current version of the items, the most recent time the items were modified, and the entities that performed the most recent item modification. In the case where the items are similar to those described previously with reference to FIG. 4, this data may be determined, for example, using the "version" attribute of the "sync" element, the "when" attribute of the "history" element, and "by" attribute of the "history" element, respectively. In such an implementation, the version data may be compared first, and an item with a greater version number may be determined to be the winning item. If both items have the same version, the most recent modification time may be compared, and the item with the more recent modification time may be determined to be the winning item. If both modifications were performed at the same time (for example, within the same second), then the entities that performed the modifications may be compared, and the item that has the entity with the "greater" value—as determined by text comparison, for example—may be determined to be the winning item. In implementations where the modification time and modifying entity are not necessarily required to be defined for each item, a comparison may determine that a winning item is the item that has data for a particular field—for example, if only one of the items has a modification time defined, that item may be determined to be the winner in a comparison of modification times.
In an exemplary implementation of operation 815, it is determined if the items are considered the "same" for the purposes of updating the local item. In one implementation, this operation may use the results of the previous operation 810. If neither item was identified as the winning item in operation 810, then the items may be considered to be the same, and the operational flow 800 may end. If operation 810 determined a winning item and a losing item, then the items may be determined to not be the same, and the operational flow 800 may proceed to operation 820. Note that in some implementations, the determination of whether the items are the same may use only the synchronization data associated with each item—like the version, modification time, and modifying entity—as described above, for example. In these or other implementations, the determination of whether the items are the same may not use item data, like contact information when the item represents a contact, image information when the item represents an image, and so on. This may mean that the item data associated with each of the two items is different even when the items are determined to be the same in this operation, and vice versa.
In at least one implementation of operation 820, it may be determined whether the local item needs to be updated. For example, when the operational flow 800 exists in the context of some other set of operations that provide a foreign item and a local item, like when the operational flow is executed as part of the merge operational flow 700, this operation may determine if the local item should be updated. In some implementations, it may be determined that the local item should be updated if the foreign item was determined to be the winning item. For example, this might be the case if the foreign item had a greater version number than the local item or had a more recent modification time than the local item. If the local item needs to be updated, the operational flow 800 proceeds to operation 825; otherwise, the operational flow ends.
In an exemplary implementation of operation 825, the local item may be updated. The implementation of this operation may vary according to how, for example, local items are stored. In some implementations, this operation may be performed by modifying a database record or records, a data structure or data structures, and so on, that may store data about the local items, by copying data from the foreign item. In other implementations, this operation may be performed by copying information from the foreign item into a feed document maintained locally, and so on. In at least some cases, both the synchronization data and the item data may be copied and used to update the local item. This means that, as a result, the local item now may have the same item data, same update history, same version, and so on, as the foreign item.
Turning now to FIG. 9, shown therein is an exemplary generalized operational flow 900 that includes operations that might be performed when processing conflicts. In some implementations, the steps described in FIG. 9 may be used as all or part of an implementation of operation 745 described previously with reference to FIG. 7. This description of FIG. 9 may be made with reference to other figures. However, it should be understood that the operational flow described with reference to FIG. 9 is not intended to be limited to being used with the elements described with reference to these other figures. In addition, while the exemplary operational flow of FIG. 9 indicates a particular order of execution, in one or more alternative embodiments the operations may be ordered differently. Furthermore, while the exemplary operational flow contains multiple steps, it should be recognized that in some implementations at least some of these operations may be combined or executed contemporaneously.
In an exemplary implementation of operation 910, it may be determined whether the two presented items are in conflict. In this context, the operational flow 900 may be assumed to be operating with two items. Such items may be a winning item and losing item, as identified, for example, by the operations of operational flow 800 described previously with reference to FIG. 8. Such items may also be a foreign item and a local item, as described previously, for example, with reference to FIG. 7. In addition, as used herein, the term "in conflict" may refer to the case where separate modifications were made independently to the same item. For example, suppose the same item is modified by two different endpoints, and neither endpoint knows of the other endpoint's modification at the time the endpoint is making its own modification. Such items might be determined to be in conflict, for example, during a merge operation. When this definition of the term "in conflict" is used, it may be possible for items that have the same item data—for example, for a contact that has the same name, address, phone number(s), and so on—to still be determined to be in conflict. This might occur, in one example, if two endpoints independently modified, say, a phone number field of a contact to the same new phone number. In some implementations, additional processing—not described herein—may be used to determine if items like this are truly different.
One procedure for determining if the two items are in conflict in operation 910 uses information about when and by whom modifications were made. For example, in an implementation that uses data described previously, for example, with reference to FIG. 4, or uses similar data, conflicts may be detected by first identifying the value of the "version" attribute of the "sync" element of the winning item, and defining this value as n. This value may then be decremented by the value of the "version" attribute of the "sync" element of the losing item, and the resulting value stored as an updated n. Then, the values of the "when" (modification time) and "by" (modifying entity) attributes of the losing item's "history" element may be compared with the values of the "when" and "by" attributes of the winning item's "update" element that corresponds to the value of n. If n is zero, then the values of the "when" and "by" attributes of the losing item's "history" element may be compared with the values of the "when" and "by" attributes of the winning item's "history" element.
In an exemplary implementation of operation 915, some or all conflict data associated with both items in question may be preserved. In this context, "preserving conflict information" may refer to the preservation of item and synchronization data associated with conflicts. For example, suppose that two items were modified independently and were subsequently determined to be in conflict. Also suppose that the data associated with the winning item was to be used, or was already used, to overwrite the data associated with the losing item. As part of conflict preservation, in some implementations the data associated with the losing item may be preserved. This may lessen or eliminate data loss, and enable, for example, subsequent user intervention to determine if the "correct" data (as defined by a user, for example) was retained.
Finally, in the case where the items were found to be in conflict—for example, they may have been found to be in conflict during operation 910—the losing item may be preserved as part of the winning item's data. In at least some implementations, this might be implemented by deleting the losing item's conflict and resolved conflict collections (perhaps by removing the losing item's "conflicts" and "resolvedconflicts" elements), and by then appending the losing item to the winning item's conflict collection, perhaps by appending the losing item's "item" element to the winning item's "conflicts" element. The previously presented example XML showing a "conflicts" element demonstrates one exemplary manner in which this might be done for the described example.
Turning now to FIG. 10, shown therein is an exemplary generalized operational flow 1000 that includes operations that might be performed as part of resolving conflicts. This description of FIG. 10 may be made with reference to other figures. However, it should be understood that the operational flow described with reference to FIG. 10 is not intended to be limited to being used with the elements described with reference to these other figures. In addition, while the exemplary operational flow of FIG. 10 indicates a particular order of execution, in one or more alternative embodiments the operations may be ordered differently. Furthermore, while the exemplary operational flow contains multiple steps, it should be recognized that in some implementations at least some of these operations may be combined or executed contemporaneously.
In an exemplary implementation of operation 1010, an item may be updated with the appropriate data. In this context, the appropriate data may be selected from one of the following: the most recent item data (i.e., this might be the case if winning item identified in a merge procedure had the correct data); the data associated with one of the members of the item's conflict collection; and from some other source, including completely new data, some user-performed manual combination of existing and/or new data, and so on. In some implementations, such an update may need to be performed using the same procedures as other updates. For example, in implementations that use the modification operations previously described with reference to FIG. 6, the item's version may be incremented, the update history may be modified, and so on.
In at least one implementation of operation 1015, conflict data may be updated after the item itself is updated in operation 1010. As part of this operation, a resolved conflict collection may be created for the item, if one does not already exist. In cases where a feed is represented using XML, this may at some point result in the creation of a "resolvedconflicts" element. Then, any members of the item's conflict collection that are deemed to no longer be relevant or valid may be moved from the conflict collection to the resolved conflict collection. In cases where a feed is represented using XML, this may at some point result in moving items that are children of the "conflicts" element to be children of the "resolvedconflicts" element. In this context, whether a member of the conflict collection is no longer relevant or valid may be determined by the user or entity resolving the conflict. In some cases this may result in all of the members of the conflict collection being moved to the resolved conflict collection, while in other cases only some, or none, of the members of the conflict collection may be moved to the resolved conflict collection. For example, if a member of the conflict collection exists that is not addressed by the data used during the update item operation 1010, that member may remain in the conflict collection. After any items have been moved to the resolved conflict collection, if the conflict collection contains no remaining items, the conflict collection itself may be deleted which, in XML feed representations, may result in the removal of the "conflicts" element.
Turning now to FIG. 11, this figure and the related discussion are intended to provide a brief and general description of an exemplary computing environment in which the various technologies described herein may be implemented. Although not required, the technologies are described herein, at least in part, in the general context of computer-executable instructions, such as program modules that are executed by a controller, processor, personal computer, or other computing device, such as the computing device 1100 illustrated in FIG. 11.
The computing device 1100 illustrated in FIG. 11, in its most basic configuration, includes at least one processing unit 1102 and memory 1104. In some implementations, the computing device 1100 may implement all or part of, for example, one of the endpoints described previously with reference to FIG. 1, such as endpoint A 110, endpoint B 120, and so on. In some implementations, the processing unit 1102 may be a general purpose central processing unit (CPU), as exists, for example, on a variety of computers, including desktop and laptop computers. Depending on the exact configuration and type of computing device, the memory 1104 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or some combination of the two. This most basic configuration is illustrated in FIG. 11 by dashed line 1106. Additionally, the computing device 1100 may also have additional features and functionality. For example, the computing device 1100 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in FIG. 11 by the removable storage 1108 and the non-removable storage 1110.
The computing device 1100 may also contain one or more communications connection(s) 1112 that allow the computing device 1100 to communicate with other devices and services. For example, the computing device might have one or more connections to other computing devices, including, for example, connections to endpoints as described previously with reference to FIG. 1. Such connections may in some cases comprise the communications means 115, also described previously with reference to FIG. 1. The computing device 1100 may also have one or more input device(s) 1114 such as an image input devices like cameras or scanners, keyboards, mice, pens, voice input devices including microphone arrays, touch input devices, and so on. One or more output device(s) 1116 such as a display, speakers, printer, and so on, may also be included in the computing device 1100.
Those skilled in the art will appreciate that the technologies described herein may be practiced with computing devices other than the computing device 1100 illustrated in FIG. 11. For example, and without limitation, the technologies described herein may likewise be practiced in hand-held devices including mobile telephones and PDAs, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Each of these computing devices may be described, at some level of detail, by the system of FIG. 11, or may be described differently.
processing the item management response, wherein the processing comprises displaying a user interface representation configured to allow identification of a second item management action and initiation of a second item management request associated with the second item management action.
2. The method of claim 1 wherein the item management action is one of: listing a set of items; retrieving item data for an item; updating item data for a second item; deleting a third item; and creating a new item.
3. The method of claim 1, wherein the item management response includes the user interface representation.
4. The method of claim 3 wherein the user interface representation comprises HTML.
5. The method of claim 3 wherein the user interface representation comprises executable code that, when executed, communicates the second item management request.
6. The method of claim 1, wherein the item management response includes data that is associated with the item management action and the data is not immediately usable to provide the user interface representation.
7. The method of claim 6 wherein the data is represented in one of: a JSON format or a SOAP format.
communicating a third item management request when the item management response indicates that the item management request would cause a conflict.
creating a new update element associated with the sync data element and further associated with at least one of: a previous most recent modification time or a previous most recent modifying entity.
communicating an item management response to the client endpoint.
11. The method of claim 9, wherein the at least one item management request further comprises another item management action to: list a set of items; retrieve item data for an item; update item data for a second item; delete a third item; or create a new item.
communicating an item management response to the client endpoint that includes: JSON data, SOAP data, or HTML data.
updating at least one of: a most recent modification time history attribute associated with the sync data element and a most recent modifying entity history attribute associated with the sync data element.
defining a second sync data element in the feed that is related to the second item data element and that comprises an initial version value, a unique identifier, and a new update history with at least one of: a modification time attribute or a modifying entity attribute.
15. The method of claim 9 wherein an endpoint that performs the requested item management action also stores information used to generate the feed in a storage module associated with the endpoint.
16. The method of claim 9 wherein an endpoint performs the requested item management action and information used to generate the feed is stored in a storage module associated with a second endpoint, and the endpoint and the second endpoint are not the same endpoint.
using the schema information to interpret property information associated with the property.
store information used to generate the feed.
"Front Page Atom Wiki; The Atom Project", Retrieved at <<http://intertwingly.net/wiki/pie/FrontPage>>, Apr. 5, 2007.
"Front Page Atom Wiki; The Atom Project", Retrieved at >, Apr. 5, 2007.
"Google Data API's (Beta) Developers Guide; Google Data API's Overview", Retrieved at <<http://code.google.com/apis/gdata/overview.html>>, , Apr. 5, 2007.
"Google Data API's (Beta) Developers Guide; Google Data API's Overview", Retrieved at >, , Apr. 5, 2007.
"Microsoft Team RSS Blog, SSE Update and Tutorial", Retrieved at <<http://blogs.msdn.com/rssteam/archive/2006/01/25/517473.aspx>>, Jan. 25, 2006.
"Microsoft Team RSS Blog, SSE Update and Tutorial", Retrieved at >, Jan. 25, 2006.
"Microsoft Team RSS Blog; More on SSE", Retrieved at <<http://blogs.msdn.com/rssteam/archive/2005/12/07/501326.aspx>>, Dec. 7, 2005.
"Microsoft Team RSS Blog; More on SSE", Retrieved at >, Dec. 7, 2005.
"Microsoft Team RSS Blog; Simple Sharing Extensions for RSS and OPML", Retrieved at <<http://blogs.msdn.com/rssteam/archive/2005/12/01/498704.aspx>>, Dec. 1, 2005.
"Microsoft Team RSS Blog; Simple Sharing Extensions for RSS and OPML", Retrieved at >, Dec. 1, 2005.
"RSSOwl | RSS / RDF / Atom Newsreader", http://www.dirfile.com/rssowl-rss-rdf-atom-newsreader.htm.
"RSSOwl | RSS / RDF / Atom Newsreader", http://www.dirfile.com/rssowl—rss—rdf—atom—newsreader.htm.
Atom Enabled, "What is Atom?", Retrieved at <<http://atomenabled.org>>, Apr. 5, 2007.
Atom Enabled, "What is Atom?", Retrieved at >, Apr. 5, 2007.
Attensa Inc., "Enterprise RSS the Center of Attention", 111 SW 5th Ave. Suite 2260 Portland, OR 97204, Dated May 2006, pp. 1-11.
Benoit Marchal, "Working XML: Expand RSS capabilities with RSS extensions", Retrieved at <<http://www-128.ibm.com/developerworks/xml/library/x-wxxm36.html>>, Aug. 15, 2006.
Benoit Marchal, "Working XML: Expand RSS capabilities with RSS extensions", Retrieved at >, Aug. 15, 2006.
Cori Shlegel, "Simple Sharing Extensions Up Close", Retrieved at <<http://kinrowan.net/blog/wp/archives/2005/11/23/sse-up-close>>.
Cori Shlegel, "Simple Sharing Extensions Up Close", Retrieved at >.
Dave Winer, "RFC: MetaWeblog API", Retrieved at <<http://www.xmlrpc.com/metaWeblogApi>>, Mar. 14, 2002.
Dave Winer, "RFC: MetaWeblog API", Retrieved at >, Mar. 14, 2002.
Dion Hinchcliffe, "How Simple Sharing Extensions Will Change the Web", Retrieved at <<http://web2.wsj2.com/how-simple-sharing-extensions-will-change-the-web.htm>>.
Dion Hinchcliffe, "How Simple Sharing Extensions Will Change the Web", Retrieved at <<http://web2.wsj2.com/how—simple—sharing—extensions—will—change—the—web.htm>>.
Ektron Inc, "Ektron CMS200", pp. 1-3.
Heinz Wittenbrink, "RSS and Atom Understanding and Implementing Content Feeds and Syndication", Dated Nov. 2005, pp. 1-37.
J. Gregorio, et al., "The Atom Publishing Protocol", Retrieved at <<http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-14.txt>>, Copyright The IETF Trust 2007, Mar. 4, 2007.
J. Gregorio, et al., "The Atom Publishing Protocol", Retrieved at >, Copyright The IETF Trust 2007, Mar. 4, 2007.
Jon Udell, "Dueling Simplicities", Retrieved at <<http://weblog.infoworld.com/udell/2005/11/22.html>>, Nov. 22, 2005.
Jon Udell, "Dueling Simplicities", Retrieved at >, Nov. 22, 2005.
Ken Rimey, "Version Headers for Flexible Synchronization and Conflict Resolution", Retrieved at <<http://www.hiit.fi/publications/pub—files/hiit-2004-3.pdf>>, Nov. 22, 2004.
Ken Rimey, "Version Headers for Flexible Synchronization and Conflict Resolution", Retrieved at >, Nov. 22, 2004.
Leonard Kawell Jr., et al, "Replicated Document Management in a Group Communication System", Retrieved at <<http://delivery.acm.org/10.1145/1030000/1024798/p395-kawell.pdf?key1=1024798&key2=1402853611&coll=GUIDE&dl=GUIDE&CFID=6163663&CFTOKEN=68289132>>, Portland, Or., Sep. 26-28, 1998.
MSDN, "Frequently Asked Questions For Simple Sharing Extensions (SSE)", Retrieved at <<http://msdn.microsoft.com/xml/rss/ssefaq/>>, Copyright 2006 Microsoft Corporation.
MSDN, "Frequently Asked Questions For Simple Sharing Extensions (SSE)", Retrieved at >, Copyright 2006 Microsoft Corporation.
Ozzie, et al., "Simple Sharing Extensions For Atom And Rss", Retrieved at <<http://msdn.microsoft.com/en-us/xml/bb510102.aspx>>, May 7, 2007.
Ozzie, et al., "Simple Sharing Extensions For Atom And Rss", Retrieved at >, May 7, 2007.
Ray Ozzie, "Really Simple Sharing", Retrieved at <<http://rayozzie.spaces.live.com/blog/cns!FB3017FBB9B2E142!175.entry>>.
Ray Ozzie, "Really Simple Sharing", Retrieved at >.
Vadim Zaliva, et al., "Enhanced "enclosures" support in RSS and ATOM Syndication", Retrieved at <<http://www.crocodile.org/lord/RSSenclosures/RSSenclosures.pdf>>, Dec. 15, 2004.
Vadim Zaliva, et al., "Enhanced "enclosures" support in RSS and ATOM Syndication", Retrieved at >, Dec. 15, 2004.
Zimbra, "A Pint of Ale-Ajax Linking and Embedding", Retrieved at <<http://www.zimbra.com/blog/archives/2006/04/zimbra-ale-ajax-linking-and-embedding.html>>, Apr. 3, 2006.
Zimbra, "A Pint of Ale—Ajax Linking and Embedding", Retrieved at <<http://www.zimbra.com/blog/archives/2006/04/zimbra—ale-ajax—linking—and—embedding.html>>, Apr. 3, 2006.


text:
Actress Srinda Arhaan Is A 'Simple Girl' In Nivin Pauly's Next Film
BY Niveda Manohar On October 4, 2016
Actress Srinda Arhaan, who garnered attention through her the film 1983, will be acting in Nivin Pauly's next film, Njandukalude Naattil Oridavela. This will be Srinda's third film with Nivin Pauly after Thattathin Maraiyathu and 1983. Ahaana Krishna will play the leading role in this film.
Talking to Times of India, Srinda said "I play Mary, a simple girl in the family entertainer who is neither too traditional nor ultra-modern. It is going to be my second film with Nivin and all I can say is that the humour will be similar to that in 1983."
In 1983, she played the role of Susheela, Nivin's naive wife. Her character was humourous and brought her much deserved attention.
"Nivin told me about the film a few months ago. And when I heard the storyline, I instantly fell in love with my part. It would give me enough space to experiment and explore my acting skills. It is a family entertainer with enough suspense elements. Though the movie deals with a serious subject, it is narrated in a lighter vein" Srinda added.
Srinda made her debut in Aashiq Abu's 2012 thriller 22 Female Kottayam and did some prominent roles in films like Annayum Rasoolum, Masala Republic and Amar Akbar Anthony.
Njandukalude Naattil Oridavela's director Althaf appeared in a minor role in Nivin Pauly's Premam. The film will have cast that includes actors from Premam, like Krishna Shankar, Siju Wilson and Sharafudheen.
Malayalam News March 2, 2016
Kerala State Awards Snubs Premam; Fans Outraged
Malayalam Features December 23, 2015
Malayalam Movies In 2015: Our Favourites
Tamil News September 13, 2016
Nivin Pauly And Ahaana Krishna In Althaf's Directorial Debut
Director Gautham Ramachandran On Ashok Selvan's Cameo In Ulidavaru Kandanthe Remake
Vikram Turned Down Big-Budget Hollywood Film Offer
Nayanthara-Starrer 'Kolaiyuthir Kaalam' To Release On July 26
Mani Ratnam's Production 'Vaanam Kottatum' Begins
Shiva's Next 'Sumo' Nears Completion
Vadivelu Approaches Shankar, Chimbu Deven To Settle Issues Over '24am Pulikesi'

redpajama_set_name: RedPajamaCommonCrawl