Re: More History comments

Tansley, Robert wrote:

>>The question is why you decided to use BND1:1 rather than BND1:2.  If 
>>the choice of BND1:1 was required because the resource at 
>>that node is 
>>identified by a content based identifier, then information 
>>has been lost 
>>about the distinct nature of the two instances.  The graph 
>>looks wrong; 
>>the second chain is logically independent of the first, yet you've 
>>combined the nodes early in the chain, dividing them only where the 
>>content has changed.  I think you instead should consider the 
>>instance 
>>chain to be independent of the content (see attachment.)
>>    
>>
>
>Hi Kevin,
>
>Your attachment shows the logical conclusion of following the logic I was trying to describe; that basically, if you change anything in the archive, since things in the archive are related changing one thing changes the situation that everything related to that changes.  This could prove to be a scalability issue; if every minor change in the archive results in a lot of things having a different situation, then the history system will rapidly become an enormous corpus of data.  Maybe that's OK.  My point is that as far as I'm aware this vital issue hasn't been looked at even vaguely in the original or current work of the History system.
>
> Robert Tansley / Hewlett-Packard Laboratories / (+1) 617 551 7624
>  
>
Ah, my apologies for being dense.

I'm not sure that the corpus really grows that rapidly though as it is 
only the nodes that have to be instantiated multiple times.  The content 
pointed to by those nodes can shared between all of the nodes that have 
that content (think C++ smart pointers, e.g: string class).  The 
overhead of the structure should be manageably small when compared with 
the size of the data being pointed to.

I do think that it is worthwhile (for size management, but also for 
navigability) to avoid automatic archive of changes.  Instead archived 
history should show 'relevant' changes, where relevance is determined 
under application control.  For Simile that might mean only writing to 
the archive once when a workflow has completed entry of a new document, 
rather than seperately for each step in the workflow.

Cheers,
-kls

-- 
========================================================
   Kevin Smathers                kevin.smathers@hp.com    
   Hewlett-Packard               kevin@ank.com            
   Palo Alto Research Lab                                 
   1501 Page Mill Rd.            650-857-4477 work        
   M/S 1135                      650-852-8186 fax         
   Palo Alto, CA 94304           510-247-1031 home        
========================================================
use "Standard::Disclaimer";
carp("This message was printed on 100% recycled bits.");

Received on Friday, 23 May 2003 03:17:25 UTC