Method, computer program product, and data structure for publishing a data object over a store and forward transport6324587Abstract A method and computer program product instituting an entirely client-based system for sharing messages and other data objects is provided. Communication between clients occurs over a generic store and forward transport such as the Internet message protocol described in RFC 822 and implemented on the Internet or other wide area network. A message or other data object is originally maintained by a "publication" client that publishes the data object and any modifications thereto to one or more "subscription" clients that will each maintain a copy thereof. As modifications are made by a client (either publication or subscription) to the client copy of the data object, the modified data object is sent, using the store and forward transport, to the publication client to update the data object. Once the data object is updated by the publication client, copies of the modified data object are sent using the store and forward transport to each subscription client so that the subscription client may update the subscription copy. One embodiment of the present invention designates a messaging folder containing one or more data objects as a publication folder (managed by a publication client) that is replicated out to subscription clients over the store and forward transport. The subscription clients each have a corresponding subscription folder wherein the subscription client copies of the data objects are maintained. Any modifications to the data objects are passed to the publication client for verification, replacement in the publication folder, and distribution out to each subscription client for replacement in the corresponding subscription folder. The addition of new data objects or the deletion of existing data objects are handled in like manner through the publication client. Claims What is claimed and desired to be secured by United States Letters Patent is: Description BACKGROUND OF THE INVENTION
TABLE 1
Permissions
Role/Permissions Description
Editor An editor has total access to all data objects in a
particular publication. Therefore, an editor can create
new data objects, and read, edit, or delete any existing
data object in the publication folder.
Author An author may create new data objects as well as read
all data objects in the publication folder. An author,
however, may only edit and delete data objects in the
publication folder that are owned by that particular
author.
Contributor A contributor may create new data objects and read all
data objects in the publication. A contributor cannot
edit or delete any data objects from the publication
folder.
Reviewer A reviewer may only read data objects in the publica-
tion folder. Consequently, a reviewer cannot add new
data objects nor edit or delete any existing data objects
in the publication folder.
Non-compliant Since a non-compliant reviewer is receiving all data
Reviewer objects as attachments to messages that are received
in the standard inbox, there is not the subscription
folder associated therewith. Like any other reviewer,
a non-compliant reviewer will simply be able to read
the data objects as they are received in the inbox and
cannot add new data objects at an existing or delete
existing data objects. Furthermore, a non-compliant
reviewer differs from a compliant reviewer in that a
new message is received and separately handled by the
user for each modification made to a data object in the
publication folder while the compliant reviewer will
replace the particular data object in the subscription
folder with the revised data object.
Referring to FIG. 8C, a subscribers table is shown that lists information regarding the subscribers that are associated with a subscription client. A subscribers table may contain a variety of information, including but not limited to, a subscription client ID 218, a reference 219 that can be used to access a database, such as an address book, of subscriber information, a visual name 220 that can be used when the subscriber name is to be displayed, address 221 where messages can be sent over a store and forward transport, and an address type 222 that identifies the format or type of e-mail address and transport protocol, such as SMTP or X400. Note that much of the information is optional in that it can be obtained by reference through use of the reference 219 into a more complete database. As shown, the reference 219 is used to access a database of information to establish the other fields when the publication is originally set up. Those skilled in the art will note that other embodiments may use the reference 219 for periodically updating the other fields as necessary even after the initial set up. Referring to FIG. 8D, a submission table is shown that is used by a subscription client when submitting a modified data object to the publication client. An entry is made in the submission table upon sending the modified data object to the publication client and removed when the publication client sends the revised data object back to the subscription client during the normal course of processing. Such update processing will be explained hereafter in greater detail in the discussion surrounding FIGS. 10, 16, and 18. Each entry on the submission table may contain, but is not limited to, the following fields: a publication ID 223 to identify the publication to which the table entry pertains, an entry number 224 used as a reference to indicate which data object within the publication has been submitted, a version number 226 that tells which version of the data object is sent having the modifications, a submission ID 228 for identifying the particular submission to the publication client, a data object reference 229 so that the actual data object may be found or identified, status flags 230 that are used by the client in managing the subscription, and a last modification time 231 that tracks when the data object of the submission was last modified. Typically, the publication ID 223 and the submission item ID 228 are implemented as GUIDs. The entry number 224 is an integer that uniquely identifies a particular data object within the publication folder. The entry number 224 is assigned when a data object is initially made part of the publication either by being in a folder selected for publication or later added to the publication folder. The highest value for the entry number 224 is tracked and new data objects will receive the next higher number. When a data object is deleted, the entry number is not typically reused. The version number 226 will only be incremented by the publication client and is used to track the current state of a data object. If a modified data object is received by a publication client, it will reference the version number of the data objects upon which the modification was made. The modified data object will be assigned the incremented version number once accepted by the publication client and placed in the publication folder. The version number may indicate how many modifications have been made to the data object. Referring now to FIG. 8D, the TOC data structure is shown in more detail. There is one TOC for each publication folder or subscription folder that lists the data objects contained therein. Each row or entry of the TOC table may include but is not limited to the following fields: An entry number 232, a version number 234, status flags 236, the data object owner 238, and a data object reference 240. Again, the entry number 232 is a way to numerically reference the data object while the version number 234 indicates the current version of a particular data object. The status flags 236 will indicate whether a data object has been deleted amongst other status. The field indicating the owner 238 is used in verifying permissions to assure that a particular subscription client has the requisite authority to edit or delete a particular data object. In order to coordinate activities between a publication client and one or more subscription clients, messages are passed back and forth over a store and forward transport. In one embodiment of the present invention using Microsoft Exchange messaging services, there is the ability to send different types of messages that can be recognized by the respective publication or subscription clients who are fully compliant with applications/subscription protocol. There are update messages that are sent from a subscription client to a publication client, and from a publication client to a subscription client. Additionally, there are request messages sent from a subscription client to a publication client and synchronization state or syncstate messages sent from a publication client to a subscription client. Each message type has associated with it certain data fields or properties associated therewith that contain control information that will be used by the respective publication client or subscription client. Furthermore, a data object, if applicable to the message, will be included as an attachment. Note that in some implementations all the properties may be grouped together and included as an attachment to the message or a data object may be incorporated into the body of the message. Those skilled in the art will recognize that many variations exist in terms of organizing the control information and data objects for transport in a message format over a store and forward transport. An update message acts as a wrapper for a data object being distributed out to the various subscription clients from the publication client by including the data object as an attachment. Additionally, subscription clients will include a modified data object as an attachment to an update message when submitting modifications to a publication client. Furthermore, a delete indication may also be sent by means of the update message in order to indicate the deletion of a particular data object. Below, in Table 2, is a list of properties that may be included in an update message and their appropriate description. Note that other properties may also be used depending on the implementation.
TABLE 2
Update Message Properties
Properties Description
Entry Number This property specifies the entry number of the
attached or referenced data object that was as-
signed to the data object upon creation or initial
cataloging of the publication client and is used
as a reference.
Publisher Flag The publisher flags are used to indicate miscel-
laneous types of information. One flag will
indicate whether or not the update message is
being sent by the publication client or the sub-
scription client.
Owner ID This field specifies the subscription client ID of
the owner of the data object during a create or
modify operation. If the update message is from
the publication client, this is the owner ID for
the data object attached to the update message.
The net effect is that the subscription client
owning the data object will have access to the
message and data object according to his permis-
sions while non-owners will have read-only
access. If the update message is from a subscrip-
tion client, the owner ID is set to match the
subscription client ID of the subscription client
if subscription client is requesting or retaining
ownership, otherwise the property will be null.
Publication ID This property indicates the publication ID to
which the update message pertains.
Submission ID The submission ID is a GUID associated with an
update message when an attached data object is
created or modified. The subscription client uses
the GUID to reference the submission before the
publication client has assigned an actual entry
number for a new message.
Subscription client ID It is not valid if the update message originates
from a publication client.
Version Number Version number tracks the current version of a
data object. Only the publication client is able
to increment this number.
The update message processing for the publication is explained in more detail hereafter in the discussion surrounding FIG. 10. Likewise, the update message processing for a subscription client is explained in greater detail hereafter in the discussion surrounding FIG. 16. A request message is sent from a subscription client to a publication client in order to request a certain type of action. Typically, a specific request type is given that will determine the action taken by the publication client. Some common request types are a request for activation of a subscription, a request for cancellation of a subscription, a request for missing data objects, and a request for a synchronization message on the publication folder. Each of these request types will be explained in more detail as part of the discussion surrounding FIG. 11. Below, in Table 3, are some of the properties that may be associated with a request message.
TABLE 3
Request Message Properties
Property Description
Missing Objects The missing data objects property indicates data
objects needed by the requesting subscription
client. The publication client will send the latest
version of the requested data objects to the sub-
scription client in response to the request mes-
sage. This process is explained from the publica-
tion client side in more detail in the discussion
surrounding FIG. 11 and with the subscription
client in the discussion surrounding FIG. 17 and
FIG. 19.
Publication ID Publication ID is a GUID indicating the publica-
tion folder for which the request is made.
Request Type Request type is a set of flags that indicate the
nature of processing associated with the request.
Some sample types are the activation of a new
request, the cancellation of an active subscription,
a request for missing messages, and a request for
synchronization with the publication client. Note
that in some cases, more than one type may be
processed in the same request message (e.g.,
requesting to activate a subscription and re-
questing missing messages in order to create the
subscription folder).
Subscription client ID Indicates the subscription client ID of the
subscription client.
A synchronization state or syncstate message is sent from the publication client to a subscription client based on either a predetermined criteria or a specific subscription client request. The purpose of the syncstate message is to send enough information to the subscription client so that it may verify that it has the most current and up-to-date version of all the data objects in the publication folder. Typically, this is done by attaching the publication client's TOC with the syncstate message. A more detailed description of the syncstate processing by a subscription client is explained in the discussion surrounding FIG. 17 hereafter. Below, in Table 4, is a non-exhaustive list of potential properties for the syncstate message.
TABLE 4
SyncState Message Properties
Property Description
SyncState Flags SyncState flags convey miscellaneous information
including type of syncstate message presented in
whether the message has been sent in response to
update processing.
Max Entry Number This integer number indicates the highest entry
number used by the publication folder. Note that
entry numbers for data objects that have been
deleted are not reused but simply become inactive.
Permissions A setting indicating the permissions for the sub-
scription client receiving the syncstate message.
Publication ID Specifies the publication folder through a GUID.
Subscription State Indicates the state of the subscription, namely:
active, inactive, or pending.
Transmitted TOC This is the TOC of the publication client that
contains the most up-to-date information on all
the data objects stored therein.
In order to understand how publication clients and subscription clients work and interact one with another, FIGS. 9 through 19 are presented. FIGS. 9 through 13A and 13B present the publication client processing while FIGS. 10 through 19 present the subscription client processing. The interaction between the publication and subscription clients is done through processing the messages described above. Referring now to FIG. 9, a high-level flow chart showing the basic processing steps for the publication client is shown. This publication client is a thread that will monitor the folder publishing inbox 178 of FIG. 7 as well as other internal events that may be initiated by a user of the client software. The publication client receives messages and events at step 242. If an update message is detected at step 244, then the update message is processed at step 246. An update message is received by a publication client from a subscription client and typically has a new data object associated therewith or an existing data object that has been modified and needs to be placed into the publication folder and thereafter distributed out to all of the subscription clients. The update message processing will be explained in greater detail hereafter in the discussion surrounding FIG. 10. If a request message is detected at step 248, then request message processing takes place at step 250. A request message is received from a subscription client and generally contains a list of data objects that the subscription client needs in order to make the subscription folder up-to-date with the publication folder. Also, other requests such as cancellation of an active subscription or change in permissions may be made. The request message processing will be explained in greater detail hereafter in the discussion surrounding FIG. 11. If a publication folder event is detected at step 252, then publication folder event processing occurs at step 254. Publication folder events include such things as creating a new publication folder, adding a subscription client, and altering permissions for operating on folders as well as ownership of the individual data objects. The publication folder event processing will be described in greater detail hereafter surrounding the discussion of FIG. 12. If a periodic synchronization event is detected at step 256, then a syncstate message is sent to each subscription client at step 258. Because a store and forward transport is sometimes unreliable, it is important for the publication client to periodically generate a synchronization event that will allow all subscription clients to synchronize the contents of each subscription folder with the contents of the publication folder. On occasion, messages are lost in transit between publication clients and subscription clients. The processing of the syncstate message by a subscription client will be explained in more detail hereafter surrounding the discussion of FIG. 17. If a conflict resolution message is detected at step 260, then the publication client will arbitrate modification conflicts at step 262. Since subscription clients act independently of one another, and there is no synchronous transfer of messages between the subscription clients and the publication clients, two or more separate subscription clients may submit a modified data object having different modifications to the same base version. A conflict situation is detected during the update message processing (FIG. 10) and is explained in detail hereafter in the discussion surrounding 13A and 13B. Referring now to FIG. 10, the processing steps for processing an update message by the publication client are shown. Beginning at step 264, the entry number property on the update message is verified at step 266. Essentially, the entry number found in the update message is matched against an entry number in the publication folder TOC. If a new message is enclosed with the update message and the entry number matches an already existing entry number in the publication folder TOC, then the entry number is invalid for the create since a data object having that entry number already exists. Likewise, if a subscription client modifies a data object in the publication folder and the entry number doesn't match the entry number of any non-deleted publication folder TOC entry, then no data object can be located corresponding to the entry number and the entry number is again invalid. In like manner, if a subscription client deletes a data object contained in the publication folder and no matching entry can be found amongst the non-deleted publication folder TOC entries, the entry number is invalid. If any entry number is found to be invalid at step 268 as explained previously, the update message, including any attached data object, is discarded at step 270. At step 272, permissions and ownership of the subscription client for doing the indicated operation on the attached data object are assessed or verified. The subscription client's permission information is acquired from the subscription client table data structure. Because some permissions only allow deletion or modification on data objects that are owned by a particular subscription client, the subscription ID is also compared with the ownership ID found in the appropriate entry in the publication folder TOC. If the permissions and ownership are not adequate for the desired operation, as explained previously and determined at step 274, a syncstate message is sent to the subscription client having the correct permissions for that subscription client at step 276. When the subscription client receives the syncstate message, it will be able to adjust its permissions accordingly so that future impermissible updates will not be submitted. The version number property found in the update message is compared to the version number as it is found in the publication folder TOC at step 278. If the version number found in the update message does not match the version number found in the publication folder TOC for the designated data object as determined at step 280, then a modification conflict has been detected and conflict resolution processing is done at step 282. The mechanics of the conflict detection processing done during update message processing will be discussed more fulling in connection the discussion surrounding FIG. 13A hereafter. The actual resolution of the conflict is explained in the discussion surrounding FIG. 13B. The mismatch in version numbers indicates a conflict because a modified data object being submitted to a publication client should have the same version number as the same data object found in the publication folder. Since the subscription folder where the modified data object originated should be an up-to-date copy of the publication folder, the version number of the data objects should also be the same. If it is determined that the update message is creating a new data object for publication at step 284, the new data object is copied into the publication folder at step 286. Next, a new publication folder TOC entry is created at step 288. In order to create the new TOC entry, the highest current entry number will be incremented to create the new entry number and the version number will be set to 1 as this is the initial version. The owner field of the publication folder TOC entry will be filled with the owner ID property found in the update message. If the update message contains a modified data object as an attachment as determined at step 290, the existing entry for that data object in the TOC will be found and modified at step 292. The TOC entry is modified by incrementing the version number representing the modified data object that has been received in the update message and that replaces the previous version in the publication folder. Next, the modified data object is copied over the existing data object in the publication folder at step 294. Storage of previous versions of a particular data object is not currently supported and only the latest version should exist in the publication folder. Those skilled in the art will recognize that storage of previous versions of data objects could be implemented should the occasion require. If the update is for a delete operation as determined at step 296, there will be no attached data object. Using the information from the update message, the TOC entry corresponding to the data object is found in the publication folder TOC and marked as deleted at step 298. Note that the TOC entry will remain in the publication folder TOC even after deleted, and the delete will be indicated by the status flags found therein. Finally, the associated data object indicated in the update message is deleted from the publication folder at step 300. At this point, the publication folder is up-to-date with the results of the update message received from a particular subscription client. In order to reflect the changes made to the publication folder, an update message is composed and sent to each subscription client at step 302 before processing ends at step 304. Note that the processing steps shown in FIG. 10 represent the detailed description of the processing steps found in step 246 of FIG. 9. The update message will include a copy of the new or modified data object if the update is a create or modification update or will have instructions for a delete if it is a delete update. Once each subscription client receives and processes the update message, each subscription folder should reflect the state of the publication folder. Subscription client processing of an update message is explained in more detail hereafter in connection with the discussion of FIG. 16. Referring now to FIG. 11, the processing steps taken by a publication client to process a request message received from a subscription client is shown. After beginning at step 304, the type of request message is determined at step 306 by examining the request-type property of the request message. If this is a subscription activation request as determined at step 308, the status of the subscription client in the subscription client table data structure will be changed to active from pending at step 310. Note that an activation request will be received in response to a new subscription message sent to the particular subscription client so that the subscription client table will already be aware of a pending offer for subscription. The publication client will then send a syncstate message to the subscription client containing the publication folder TOC at step 312. With this information, the subscription client will be able to request all of the data objects from the publication folder so that the subscription folder can be made to mirror the contents of the publication folder. The client side processing of a syncstate message will be explained in more detail hereafter in connection with the discussion surrounding FIG. 17. If the request type is determined to be one that cancels a subscription as determined at step 314, then a further determination is made at step 316 to verify whether the subscription client exists in the subscription client table. This secondary determination needs to be made since either the publication client or the subscription client may cancel a subscription. If the publication client is the originator of the cancellation, then the subscription client will be removed from the subscription client table at this point in processing. In that case, there will be no subscription client in the subscription client table as determined at step 316, and the message will simply be discarded in step 318. If the subscription client has initiated the cancellation, then the publication client will still have the subscription client information in the subscription client table. This will be determined at step 316. For this situation, the subscription client is removed from the subscription client table at step 320. Next, a syncstate message is sent to the subscription client with a cancellation indication in step 322 so that the subscription client may become fully unsubscribed to the subscription. Note that the syncstate message having the subscription cancellation indication is processed by the subscription client as described in the discussion surrounding FIG. 17 hereafter. If the request type indicates that a list of missing messages is attached as determined at step 324, publication client will process the missing messages property and send an update message for each entry number in the list of missing messages at step 326 for the pertinent publication. In some implementations, an efficiency may be attained by sending a single message having multiple data objects attached thereto representing each data object indicated in the list of missing messages. Furthermore, it may also be advantageous to duplicate the message properties as an attachment to the message that would allow a different, and sometimes more efficient, mechanism for accessing the property values. Should the request type of the request message be a synchronization request as determined at step 327, a syncstate message is sent to the subscription client at step 328 that will include the publication folder TOC. Note that the appropriate subscription client is identified from the subscription client ID of the request message and the correct publication folder is indicated from the publication ID of the request message. With the subscription client ID, the email address and other pertinent information may be found in the subscription client table. Should the request type of the request message be a send all data objects request as determined at step 329, a separate update message is sent to the subscription client for each and every data object in the subscription at step 330. This allows a subscription client that is just getting initialized to request all data objects with a single request message. Should the request type of the request message be a permission change verification as determined at step 331, the publication client verifies that the change of permission happened properly at the subscription client. This is part of the architecture that requires a "round trip" back to the publication client before the action is completed. Finally, request message processing ends at step 333, and the processing steps shown in FIG. 11 represent the detailed description of the processing steps found in step 250 of FIG. 9. Referring now to FIG. 12, the processing of differing publication client events is shown. After beginning at step 334, the type of publication client event is determined at step 336. This determination is made through the publication client code and may be triggered by operation of the user interface by a user that is operating the publication client or some other internal publication client condition. If the type of publication event is determined to be the creation of a new publication at step 338, then a folder containing data objects is selected for publication at step 340 through the user interface of the publication client. Typically, an existing personal store folder would be selected having messages and other data objects that a user desires to share with other users. Next, a GUID is generated to identify the publication as a publication ID at step 342. The GUID or publication ID will be used to reference the selected publication folder and all underlying data objects when communicating between publication clients and subscription clients or when accessing the different data structures, such as the map table, subscription client table, and submission table. Finally, a TOC data structure is created and placed in a message that resides in the publication folder at step 344. Also, other data structures are initialized with the new publication information at step 344, such as a new entry in the map table identifying the folder with the publication ID. If the type of publication event is adding a new subscription client as determined at step 346, an entry is made in the subscription client table for a particular subscription client and publication folder at step 348. In other words, a subscription client and a publication folder as identified by a subscription client ID and a publication folder ID are entered together in the subscription client table. The email address of the subscription client is also specified so that messages may be sent using the store and forward transport, such as messages conforming to the RFC 822 specification over the Internet. Next, the status of the subscription client is marked as `pending` until the subscription client returns a request message activating the subscription. This way, the particular subscription client has ultimate control over whether or not it receives messages pertaining to a given publication. Also, the initial permissions that a subscription client will have are determined and set at step 352. The publisher (i. e., the user operating the publication client) will determine which of the roles/permissions listed in Table 1 a subscription client will be assigned. Finally, a new subscription message is sent to the designated subscription client at step 354. The subscription client side processing of a new subscription message will be explained in more detail hereafter in connection with the discussion surrounding FIG. 15. Should the type of publication event be determined to be an alteration of permissions for a subscription client or ownership of a particular data object as determined at step 356, then different paths are taken depending on whether or not a permission change is involved. If permission changes are involved as determined at step 358, a syncstate message is sent to the subscription client at step 360 containing the new permissions for that client. In this manner, the client may update its own internal information so that it may do permission checking at the subscription client before erroneously submitting an update to a publication client. Should alteration of ownership for a particular data object be involved as determined at step 358, the publication client will send an update message to each of the subscription clients for a particular publication folder indicating the change of ownership for the particular data object. Again, this feature need not be implemented in order to have a system in conformance with the present invention and may be viewed as optional. This information will be used by each subscription client to update the subscription folder TOC to indicate the change in ownership for the particular data object. The subscription client side change of ownership processing is handled as part of the processing of an update message and is explained in more detail hereafter in the discussion surrounding FIG. 16. Finally, the processing of a publication event ends at step 364. Note that the processing steps shown in FIG. 12 represent the detailed description of the processing steps found in step 254 of FIG. 9. Referring now to FIG. 13A, the processing steps for processing a conflict when a conflict is detected during update message processing by the publication client is shown. Initially, the processing begins at step 366 and it is determined whether a conflict resolution envelope has been created for the particular data object to the update message at step 368. If a conflict resolution envelope has not been created as determined at step 368, a data message that will include as attachments the current version of the conflicting data object as found in the publication folder and all other data objects that conflict with that version as they are received by the publication client during update message processing. The conflict resolution message will be placed in the publication folder of the publication client for resolution by the publisher. Eventually, as explained hereafter during the discussion surrounding FIG. 13B, the user of the publication client will open the conflict resolution envelope message and choose between the different versions of the attached data object in order to resolve the conflict. A conflict is detected when the version number of an update message having an attached data object is not equal to the version of the data object in the publication folder as explained previously. At step 370, a conflict resolution message is created for the particular data object attached to the update message. Next, the data object as found in the publication folder is attached to the newly created conflict resolution message at step 372. Note that if a conflict resolution envelope has been previously created as determined at step 368 the processing taken in steps 370 and 372 need not occur. At step 374, the data object contained in the update message is copied as an attachment to the conflict resolution message. At this point, there are at least two messages in the conflict resolution envelope that will need to be resolved. At step 376, any other editions of the data object that have been received or are otherwise received are also attached to the conflict resolution message at step 376. In this manner, the conflict resolution envelope will have at least two editions of a data object but may have more than two editions of a particular data object. The adding of the editions occurs as more update messages containing the conflicted data object are received and processed prior to the publisher resolving the conflict as explained hereafter. Finally, the conflict resolution message with the two or more additions of a particular data object attached therewith is placed at step 378 in the publisher's publication folder before ending the processing sequence at step 380. Note that because the publication client is "sending" the message to itself by placing the message in the publication folder, it has the ability to add further editions of a conflicting data object as they are received in forthcoming update message processing by retrieving the message if it hasn't been processed. In this manner, if the conflict resolution envelope has been created as determined at step 368, and the user has not resolved the conflict as explained in the discussions surrounding FIG. 13B, then the message may be accessed in the publication folder and additional attachments representing other editions of the particular data object can be made thereto and the message would be left in the publication folder at step 378. Note that this is simply one example of conflict detection and notification, and those skilled in the art may use others that would remain in harmony with the present invention. The conflict detection and notification processing ends at step 380 where normal publication client update message processing continues. Note that the processing steps shown in FIG. 13A represent the detailed description of the processing steps found in step 282 of FIG. 10. Refering now to FIG. 13B, the processing steps taken by the publication client as operated by a user (e.g., the publisher) to resolve the conflict are shown. After beginning at step 382, the publisher causes the conflict resolution message to be opened at step 384. The user will then review all attached editions of the data object at step 386 in order to determine which of the conflicting data objects should be placed into the publication folder and be distributed out to each of the subscription clients. Part of the review process may include editing one of the editions of the data object to consolidate the revisions made in one or more of the other attached editions of the data object. This allows all the individual revisions to be in a single data object. This would be beneficial if a paper had been distributed out to different subscription clients and each had made different editing changes that would be desirable to have in the paper. At step 388, the user selects the correct edition of the data object amongst the attached editions of the data object and all the unselected data objects are then ignored at step 390. Alternatively, some implementations may choose to simply delete unselected data objects. Furthermore, all of the items in the conflict resolution envelope may be chosen for inclusion. Those skilled in the art will note that any number may be chosen for inclusion in the publication according depending on the system implementation and all such variations are contemplated within the scope of the present invention. The TOC for the publication folder is modified by finding the entry corresponding to the data object and incrementing the version number at step 392. Finally, the selected data object is copied into the publication folder and replaces whatever version of the data object was there previously if only one was selected. If multiple or all data objects were selected, then the extra ones are added into the publication with a create message as newly created data objects for the publication. At this point, the publication folder has the latest version of the data object that incorporates the resolution of the conflicting data objects as determined by the user of the publication client. Finally, an update message is sent to each subscription client at step 396 before ending at step 398. Note that the processing steps shown in FIG. 13B represent the detailed description of the processing steps found in step 262 of FIG. 9. After each subscription client processes the update message, each subscription folder will be up-to-date with the publication folder. The subscription client side update message processing by a subscription client as will be explained hereafter in more detail in the discussion surrounding FIG. 16. Referring now to FIG. 14, a flow chart illustrating the high-level steps taken by a subscription client in processing messages received from a publication client and internal events is shown. The subscription client may be a processing thread that monitors the folder publishing inbox for messages sent to that subscription client. The subscription client receives messages and events at step 400 and should a new subscription message be detected at step 402, the subscription client will process the new subscription message at step 404. The details of the processing of a new subscription message will be explained in more detail in connection with discussion surrounding FIG. 15 hereafter. A new subscription message is typically received in the normal inbox of a client able to receive messages over the store and forward transport as a standard email message that the user will read in order to determine whether or not to accept the invitation to the publication. Ideally, the client will be compliant with the publication/subscription protocol and be able to respond accordingly. If an update message is detected at step 406, the subscription client will process the update message at step 408, which will be explained in more detail during the discussion surrounding FIG. 16 hereafter. Update messages typically will contain the data objects to be placed into a subscription folder as they are updated at the publication client and distributed outward to the various subscription clients for placement into the subscription folders. If a synchronization state or syncstate message is detected at step 410, then syncstate message processing occurs at step 412 and will be explained in more detail during the discussion of FIG. 17 hereafter. Syncstate messages are useful for detecting anomalies in the current state of the subscription folder so that missing or out-of-date data objects may be requested from the publication client. If a data object submission event is detected at step 414, the data object submission processing occurs at step 416 and will be explained in greater detail during the discussion of FIG. 18 hereafter. A data object submission event may be triggered by a user using the user interface or in some other fashion so that it is desirable to send a data object to the publication client. At step 418, a subscription client status event may be detected. If so, the processing of the subscription client status event occurs at step 420 and will be explained in detail during the discussion of FIG. 19 hereafter. A subscription client status event would be such things as a user desiring to cancel the subscription or if the subscription client discovers a suspicious state in the subscription folder. Referring now to FIG. 15, the processing steps taken by a subscription client when a new subscription message received is shown. After beginning at step 422, the user opens the message and there is a prompt for the user at step 424 for indicating acceptance of the subscription offer. Note that in some implementations a general message is sent to the user's inbox under the assumption that the subscription client software may not yet be installed for a particular client. Acceptance of a subscription would also include initially downloading and running the subscription client software that has been attached to the new subscription message. If the subscription client software already exists at the client, then no downloading need occur and processing may proceed directly. In either case, the processing illustrated in FIG. 15 is for a compliant subscription client. A non-compliant subscription client will simply receive subscription messages until the publication client manually cancels the non-compliant subscription client from the subscription. If the user does not accept a subscription as detected at step 426, a request message indicating cancellation is sent to the publication client at step 428 before ending processing at step 430. When the publication client receives the request message indicating cancellation, it will remove the subscription client from the subscription client table managed at the publication client and will no longer send messages to this particular subscription client. If the user has chosen to accept a subscription as indicated at step 426, access is verified to the indicated client folder at step 32. As part of accepting a subscription, the user will previously have indicated a particular folder as the subscription folder. Before data messages may be placed therein, the existence and access to the designated folder must be verified. This may entail creating the folder if it does not already exist. Next, the map table is updated and permissions are recorded at the client so that the client may do its own permission checking before submitting data objects to a publication client at step 434. At step 436, a TOC is created for the subscription folder and placed inside a data message stored in the designated subscription folder located in the map table. Since no data objects are currently in the subscription folder, the table will have no entries at this time. Finally, a request indicating the acceptance of the subscription is sent to the publication client. Returned in this request message will be the subscription client ID and the publication ID (both GUIDS). Both are sent down to the subscription client as properties of the new subscription message and will be used by the publication client for verification of the subscription. Finally, processing will end at step 430 and return to the main processing loop shown in FIG. 14. Note that the processing steps shown in FIG. 15 represent the detailed description of the processing steps found in step 404 of FIG. 14. Referring to FIG. 16, processing steps taken by a subscription client for processing an update message received form a publication client is shown. After beginning at step 440, the type or nature of the update message is analyzed at step 442. This analysis will break the type of an update into either a create update for a new data object to be added into subscription folder, a modify update to replace a data object currently existing in the subscription folder, or a delete update that includes an indication to delete a designated existing data object. If the update message is determined to be a create or modify update message at step 444, then the submission ID from the update message, if present, is matched with a corresponding submission ID in the submission table at step 446 in order to determine if this particular subscription client had submitted has revised a data object for distribution to all subscription clients. Only one of the many subscription clients receiving the update message will have actually submitted the revised data object. If it is determined that the submission ID is in the submission table at step 448, the submission entry is deleted from the table at step 450. Submission entries remain in the table so that if a client has submitted an update to the publication client, it may detect if an error has occurred for a submission when processing a syncstate message. Errors occur due to the store and forward transport that may "drop" packets such that the publication client does not receive the update and would therefore require a resubmission of a particular created or revised data object. At step 452, it is determined whether or not the update message represents a create, meaning a new data object will be added to the subscription folder, or whether it is simply a modify, meaning that the data object will replace an existing data object in the subscription folder. If the update message is determined to be a create at step 452, a new entry is added to the subscription folder TOC at step 454. This new entry will derive its entry number and version number and ownership ID from the corresponding properties found in the update message. Finally, the data object that is attached to the update message is copied into the client subscription folder at step 456. Note that if the subscription client had originally submitted the newly created data object, there is no need to copy the data object into the folder at step 456 in the current embodiment since the data object is already in existence. If the update message is a modify, as determined at step 452, the TOC entry is found and updated at step 458. This update will require a change in version number. Again, this information comes from the version number property and owner ID property of the update message. Finally, the data object that is attached to the update message is copied into the subscription folder at step 460 replacing the previous version of that data object. Note that if the subscription client had originally submitted the modified data object, there is no need to copy the data object into the folder at step 460 in the current embodiment since the data object is already in existence. As implemented, there is no storage of previous versions of a particular data object, though those skilled in the art will see that retaining past versions may be easily implemented if desired. One way of handling ownership changes to a data object without a data object modification makes use of the update message without an accompanying data object. Note that this is an optional feature that is within the scope of the invention whether included or not. On some occasions, the ownership of a data object changes without an accompanying modification to the data object itself. Should this occur, the update message will not contain the attached data object, though it will be referenced by the entry number property and publication ID property found in the update message. Should such an ownership change be detected at step 468, the TOC entry for the designated data object is modified at step 470 so that the ownership field is changed using the information from the ownership ID property of the update message. Finally, all processing for the update message ends at 472. Note that the processing steps shown in FIG. 16 represent the detailed description of the processing steps found in step 408 of FIG. 14 and that an ownership change may occur with or without other update message processing. Referring now to FIG. 17, the processing steps taken by a subscription client for processing an incoming synchronization state or syncstate message from a publication client, is shown. A syncstate message is received from a publication client and contains information regarding the status of the publication folder. This information is typically compared to the information in the subscription state folder in order to detect anomalies so that the subscription client may request necessary information. Furthermore, one or more update messages (and accompanying data object attachments) may also be attached to the syncstate message and be processed at a certain point. Initially, the type of syncstate message is analyzed in step 476 by looking at the syncstate flags property of the syncstate message. A subscription cancellation can be determined by analyzing the subscription state property of the syncstate message in order to determine whether the subscription client is currently considered inactive. If a publication cancellation syncstate message is determined at step 478, the subscription client will next determine whether the subscription client or the publication client initiated the cancellation at step 480. A client that has initiated a cancellation of a publication will previously have sent a request message to the publication client requesting the cancellation based on a user operating the user interface and the internal state of the subscription client will be marked as inactive so that update message processing can be ignored. Therefore, subscription initiated cancellations can be detected at step 480 by reference to the internal state of the subscription client. Generation of a subscription client initiated cancellation is explained in more detail hereafter in the discussion surrounding FIG. 19. If the cancellation was subscription client initiated as determined at step 480, all subscription information is removed from the subscription folder at step 482. This would require deleting the data message in the subscription folder containing the subscription folder TOC, removing any objects in the submission table referring to the publication, and removing the reference in the map table identifying the particular folder with the publication. The data objects in the subscription folder are left intact and the user may delete those as desired. Note that some implementations may desire to automatically delete the subscription folder and all data objects contained therein. At this point, both the publication client and the subscription client is fully unsubscribed to the subscription. If the subscription cancellation is not initiated by the subscription client as determined in step 480 but rather the publication client, the removal of all subscription information occurs at step 486. This will occur in the same manner as explained previously. Finally, a request message with a cancellation indication is sent at step 488 from the subscription client to the publication client in order to finalize the cancellation on the publication client. Processing of the request message by the publication client was explained previously in more detail surrounding the discussion of FIG. 11. At this point, the subscription client is fully unsubscribed to the subscription but the publication client will yet need to process the request message sent at step 488. Processing will then end at step 484 for the subscription cancellation scenario. At step 494, the TOC property is checked to determine if the publication TOC is present in the syncstate message. If the TOC is present as determined at step 494, the entries on the TOC transmitted with the syncstate message are compared with the entries on the subscription folder TOC at step 496. By making this comparison, missing data objects and out-of-date data objects are determined and included in a list of missing data objects at step 498. Furthermore, at step 498, a request message is sent from the subscription client to the publication client having the list of missing data objects. A data object is missing if an entry on the subscription folder TOC not having the entry number found on the syncstate message TOC is found. A data object is out-of-date when the version number on the subscription folder TOC is different from the version number found at the publication folder as represented by the TOC included with the syncstate message. At step 500, data objects that exist in the subscription folder but not in the publication folder are deleted. Again, this is achieved by comparing the TOC entries found in the subscription TOC with the entries found in the publication TOC that is attached to the syncstate message. The process of deleting excess data objects is achieved by removing the corresponding entries from the subscription folder TOC and erasing the actual data objects in the subscription folder. Finally, at step 502, each item existing in the submission table is identified by the publication ID and will trigger the sending of an update message having attached thereto the corresponding data object. This occurs since the update, even if previously sent, has not been received or reflected in the publication TOC indicating that it was not received by the subscription client. By resending an update message having the data object, the error of an apparent missing message is corrected. If it is determined at step 504 that the syncstate message contains a permission change, the permissions for the subscription client are recorded and changed at step 506. this is important so that a subscription client may verify any submission for conformance to the proper permissions at the subscription client level. This verification will be done as part of the submission event processing explained in more detail during the discussion of FIG. 18. After changing the permissions, a request message is sent to the publication client indicating a permission change verification at step 507. The permission change verification is used by the publication client to assure that the permission change was done correctly. Finally, processing for a syncstate message ends at step 484. Note that if a syncstate message is not a publication cancellation message, as determined in step 478 explained previously, then it may include all of the other elements of processing depending on the nature of the message. In other words, there may or may not be a TOC property representing the publication folder TOC, and there may or may not be a permissions change associated with each syncstate message. The syncstate message processing steps shown in FIG. 17 represent the detailed description of the processing steps found in step 412 of FIG. 14. Referring now to FIG. 18, the processing steps taken by a subscription client to submit a data object to a publication client are shown. Note that the event is typically originated by a user editing a data object in some way, such as creating a new data object, modifying an existing data object, or deleting an existing data object with reference to a particular subscription folder. When the particular editing operation is completed, then the event and accompanying data object (if necessary) are ready for submission to the publication client. For an edit involving a create situation, the newly created data object is initially stored in the subscription folder and detected by the subscription client. This will cause the item to be automatically propagated to the publication client as a newly created data object with the accompanying modification to the submission table. In like manner, if an existing data object is modified, the data object is changed in the subscription folder, detected by the subscription client, and propagated to the publication client after the appropriate submission table entry has been made. Also, a delete operation works in the same manner with the subscription client detecting that a data object was deleted from the subscription folder, making a submission table entry, and mailing notification of delete to the publication client. After beginning at step 508, the type of submission event is analyzed at step 510. If it is determined that this is a newly created data object at step 512, the subscription client will initially verify that create permissions exist at step 514 in order to complete the operation. As explained previously, the permissions for a subscription client combined with the ownership of a particular data object determine whether or not an intended operation may be achieved. Should the permission check fail, the subscription client will essentially ignore the submission and the data object will not be propagated. Next, at step 518, a submission ID is generated for this submission (typically a GUID). Having all the requisite information, a submission record is created and placed in the submission table at step 520. The submission table entry record will contain a reference to the location of the newly created data object should the object need to be resubmitted or otherwise accessed, along with the other information described for a submission table entry described in connection with FIG. 8D previously. Finally, an update message is sent at step 522 from the subscription client to the publication client having a create indication and the newly created data object attached therewith at step 522. At this point, the create submission is completed and the processing ends at step 524. Should the type of submission be determined to be a modification of an existing data object at step 526, the permissions for modification are verified at step 528. Assuming that the client is permitted to make a modification, the reference for the particular data object is acquired from the subscription client TOC at step 530. Should the permission check fail, the subscription client will essentially ignore the submission and the data object will not be propagated. Again, a submission ID is generated at step 532 to identify the submission and a submission | ||||||