Abstract: Disclosed are embodiments that communicate label information for documents between two enterprise computer systems. The two computer systems operate asynchronous from each other, and have limited available resources for use in buffering information passing between them. To that end, traditional API architectures that utilize method calls and return parameters do not operate well in this environment, as a first computer systems resources can become exhausted if a second computer system is able to generate data faster than the first computer system can consume it. The problem is exacerbated if an error is experienced when processing the consumed data, especially if there are no resources available to store the data until the error can be cleared. To solve this problem, the disclosed embodiments provide an ability for a consumer to request that data previously delivered to it be delivered again by the producer, in some embodiments, after a specified time delay.

Abstract: Disclosed are embodiments that communicate label information for documents between two enterprise computer systems. The two computer systems operate asynchronous from each other, and have limited available resources for use in buffering information passing between them. To that end, traditional API architectures that utilize method calls and return parameters do not operate well in this environment, as a first computer systems resources can become exhausted if a second computer system is able to generate data faster than the first computer system can consume it. The problem is exacerbated if an error is experienced when processing the consumed data, especially if there are no resources available to store the data until the error can be cleared. To solve this problem, the disclosed embodiments provide an ability for a consumer to request that data previously delivered to it be delivered again by the producer, in some embodiments, after a specified time delay.

Abstract: Disclosed are embodiments that communicate label information for documents between two enterprise computer systems. The two computer systems operate asynchronous from each other, and have limited available resources for use in buffering information passing between them. To that end, traditional API architectures that utilize method calls and return parameters do not operate well in this environment, as a first computer systems resources can become exhausted if a second computer system is able to generate data faster than the first computer system can consume it. The problem is exacerbated if an error is experienced when processing the consumed data, especially if there are no resources available to store the data until the error can be cleared. To solve this problem, the disclosed embodiments provide an ability for a consumer to request that data previously delivered to it be delivered again by the producer, in some embodiments, after a specified time delay.

Abstract: A server file replication technique is implemented with three local copies of a replicated file. First, a shadow file is a copy of the last known good version of the file on the server. Second, a local copy is the user's working copy. Whatever changes the user has made to the file are stored in the local copy. Third, a rollback file is a copy made of the local copy if the local copy changes (for example, when conflicts are resolved or the server version is copied to the local copy.) Different states exist, based on whether these copies contain differences from each other and from the server version, and based on the user's use of the document. These states guide what is done to maintain the local copies and whether conflict resolution is required.

Abstract: A dynamically configurable list management system that supports list elements of multiple content types is presented. Each list element is associated with an element type via an element type identifier. The element type identifier uniquely identifies the element type to the list management system. Each property associated with each element type is included in the list. Each property is identified by a unique property identifier. When adding a list element of a new element type to an existing list that does not include any elements of the new element type, the list management system identifies every property associated with the new element type. For each property associated with the new element type, the list management system determines which properties are not already included in the list, and adds those properties that are not already including to the list.

Abstract: A method for managing a first and second version of an electronic file is disclosed. In the method, first and second versions of an electronic file are recognized and a synchronization event is initiated. An application program interface accesses the first and second versions, compares information associated with each, generates a result and reports the result to the first software application. A second software application generates a user interface in accordance with a feature of the second software application, where the electronic file is associated with the second software application, and the user interface is displayed on a display device.

Abstract: A method for managing a first and second version of an electronic file is disclosed. In the method, first and second versions of an electronic file are recognized and a synchronization event is initiated. An application program interface accesses the first and second versions, compares information associated with each, generates a result and reports the result to the first software application. A second software application generates a user interface in accordance with a feature of the second software application, where the electronic file is associated with the second software application, and the user interface is displayed on a display device.

Abstract: A server is implemented with a modified file open action, which, when a user performs the modified open, initially opens a file without locking the file. When a user indicates (either explicitly or implicitly) that the user is attempting to or intending to open the file, the file can then be locked for editing. In this way, the default action when a user requests a file is to open the file without denying other users access to the file. Then, when the user indicates that editing should occur, the lock for the file is obtained.