I agree!<br><br>For the overhead of handling the well known problems of cacheable_data (e.g. locking during updates) this solves every objection that I can think of.<br><br>Most importantly this ensures that there is always a resolution for the identifier.<br>
<br>A simple history file (journal?) can track changes made to archived identifiers (i.e. a list of changes made to the cache - analogous to a file system journal). As I think of it there are several ways to handle this problem, all of which fit nicely within the general concept that you have made.<br>
<br><br><div class="gmail_quote">On Sun, Aug 29, 2010 at 10:06 AM,  <span dir="ltr"><<a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
More generally,<br>
<br>
protocol://authority/resource_type/resource_id[/cacheable_data]<br>
<br>
The more I look at this, the more I like it.<div><div></div><br></div></blockquote></div><br>