<a:e id="idofentry" a:r="2">
<a:c id="idofcomment" a:r="1">
<a:c id="idofcomment" a:r="2"/>
</a:c>
</a:e>
<a:e id="idofentry: a:r="3"/>
</a:f>
The requestor sends a request for all entries and comments on those entiries since a certain date. If the date request is considered reasonable, a compact atom syntax that contains,
a) a determination as to whether they support providing diffs a:ds="0" false, a:ds="1", true
b) the relavent pieces necessary to determine if,
b:1) you have a local instance of that id.
b:1:1) If yes, compare the revision (a:r) value.
b:1:1:1) If the same, ignore,
b:1:1:2) if different, the difference is determined, and stored until the compact syntax above has finished being processed.
b:1:2) If there is no local instance of that id, store the this until the process has finished.
recurse until complete.
recurse the result:
a: If you can process the diff, and they support returning just the diff, set a request header determined to specify this to the server.
b: set a header to specify to the server if you want the exact specified revision, or additional revisions if they have changed since the original query.
c: return a request for each updated or new resource, with the difference between the local revision number and the revision number on the server if appropriate.
each request is initially atomic, with the ability to be grouped if the server determines that it would be more efficient at present time to handle one request at a time, or grouped together using a conanical compression of the requested items. This would be returned in the response header such as to maintain a consistent ability to adapt at any moment to current oad on the server.
nothing is approximate, each side of the transaction has the ability to adapt to change, and to decide if it wants to handle potential differences that take place during the span between requests now, or at a later date. With each transaction, enough information is provided to quickly calculate and determine, or specify a default if the current load is past a certain threshold, while still maintaining the knowledge that updates exists, and when the load allows, make a new request based on the difference in stored values that pertain to each id it has knowledge to have differences.
If during this span, the server in which receives the request realizes that since the last request, a resource has been removed/deleted, a header can be set to specify that future calculations should be based on the new difference instead of the old.
----
In the above scenario the amount of data exchange is at a bare minimum, the processing required to calculate the differences is at a bare mininum, it maintains a level of data integrity that is granular enough to adapt to each change in the system, without requirement of extensive processing to determine this difference, while maintaining an agile/adaptible foundation that can adjust as needed without loss of data integrity on either side of the transaction.
Given the amount of data sent with initial request is at a bare minimum, this can be set in memory as the default response based on the time difference to determine the address of where to begin streaming the request, using the default a:f id="feedid" to open/close the response stream at the appropriate start and stop point of the returned stream.
Please disregard the above if I have left out obvious areas in which makes this irrelevant. Not trying to take a "this is the absolute right way to do this" and instead inject the smallest, simplest path that seems to logically provide the necessary pieces to make the transaction processing of differences as simple and efficient as possible, while doing so in a way thats just outside the box, but close enough as to not require any changes to any actual draft specifications, and instead a way to illiminate some of the concerns presented that suggested potentials areas of inefficient or innacurate behaviors that hold potential for problems down the road.
Peace :)
On 5/18/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Antone Roundy <[EMAIL PROTECTED]> [2006-05-18 20:05]:
> and in another document:
>
> <ct:comment-tracking xmlns:ct="..." xmlns:atom="..." ...>
> <atom:link rel="related" href="" of the feed" ... />
> <ct:entry ref="foo">
> <atom:link rel="comments" href="" type="..."
> hreflang="..." ct:count="5" ct:when="..." />
> <atom:link rel="comments" href="" type="..."
> hreflang="..." ct:count="3" ct:when="..." />
> </ct:entry>
> <ct:entry ref="bar">
> <atom:link rel="comments" href="" type="..."
> hreflang="..." ct:count="0" ct:when="..." />
> <atom:link rel="comments" href="" type="..."
> hreflang="..." ct:count="1" ct:when="..." />
> </ct:entry>
> ...
> </ct:comment-tracking>
>
> Of course the comment tracking document wouldn't only be
> authoritative for feeds that pointed to it with a
> comment-tracking link.
>
> This would require an extra subscription to track the comments,
> as well as understanding an additional format (as opposed to
> just an additional extension--either approach requires SOME
> additional work), but it would prevent unnecessary downloads by
> clients that aren't aware of it, and would reduce the bandwidth
> used by those that are.
>
> This approach could be generalized to enable offloading of
> other metadata that's more volatile than the entries
> themselves.
Actually, you don't really need another format. There's no reason
why you couldn't use atom:feed in place of your hypothetical
ct:comment-tracking. :-) Your ct:entry elements could almost be
atom:entry ones instead, too, except that assigning them titles
and IDs feels like overkill.
The real cost is not the cost of an extra format, but that
implementations then need to understand the FTE in order to know
to poll an extra document to retrieve the out-of-band metadata.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
