Regarding timestamps see also
http://hackaday.com/2014/12/19/nist-randomness-beacon/
q: "More esoterically, one could use the Randomness Beacon to prove
that something is newer than a certain date by including a recent
Beacon entry."
On Mon, Jan 5, 2015 at 12:07 PM, Stephan Beal <[email protected]> wrote:
> On Sun, Jan 4, 2015 at 5:29 AM, Kelly Dean <[email protected]> wrote:
>>
>> Fossil says the artifact list is supposed to be append-only, but it also
>> has clusters as artifacts that are discardable. This is conceptually
>> suboptimal.
>
>
> Very briefly, as my elbow infection is killing my left hand, but your mail
> is just too good to not respond to...
>
> For someone who just started with fossil yesterday, you've come a loooong
> way in understanding it!
>
>>
>> Fossil tries to keep the storage of content a separate matter from the
>> content itself, but doesn't fully succeed.
>
>
> Yes and no. It uses sqlite (the storage) to do a lot of the work, but the
> manifests contain all the raw metadata needed _except_ for the mapping of
> UUID to blob content (which is what the blob table does).
>
>>
>> The manifest is an essential part of the content, since it contains
>> filenames, which are themselves content. However, some manifests also
>> contain a B-card for delta compression, which is a storage matter.
>
>
> _Delta_ compression is a syntax extension for manifests only, and have no
> effect on the system outside of how their manifests are produced/parsed, so
> i would say B-cards are very much part of the metadata.
>
> _Content_ compression is indeed a storage issue, and is not mentioned
> anywhere in the manifests.
>
>> The R-card looks redundant. What's it for?
>
>
> Very short answer: largely historical to prove data fidelity. It has in the
> mean time been made optional, but fossil still calculates it by default (and
> it's a very expensive calculation).
>
>>
>> The Z-card looks redundant. The name of an artifact is a hash of it and
>> stored with it as uuid in the blob table, so you already have a way to
>> verify it.
>
>
> "blob table" ==> storage unit. The manifest uses the UUID of the blob, but
> where it's stored is an implementation detail.
>
>>
>> Do R- and Z-cards need to be cryptographically secure?
>
>
> No.
>
>>
>> If so, why not use something better than md5? If not, then why not use
>> something much faster than md5?
>
>
> Can't say - historical decision predating me.
>
>>
>> Tags for artifacts should be properties with value «true», not with value
>> «nil». If the value is «nil», that should mean the artifact _doesn't_ have
>> the specified property, which is how Emacs does it. I.e. ⌜(put
>> 'some-artifact 'some-property nil)⌝ really doesn't look like it means ‟put a
>> property on the artifact”; it looks like it means ‟remove (nullify) the
>> property from the artifact”. Instead, ⌜(put 'some-artifact 'some-property
>> t)⌝ puts a property on.
>
>
> As much as i love emacs, semantic compatibility with emacs has never been a
> goal. In the context of fossil, having a tag set does not imply
> true/false/nil - its interpretation is tag/context-specific. Most tags don't
> use values, and some reserved tags expect them to contain specific things
> (e.g. 'bgcolor' expects an HTML-style #RGB value).
>
>>
>> Does Fossil give any warning if you receive a new ticket update with a
>> timestamp preceding an update that you yourself created and with a
>> conflicting J-card? Then #2 would notice #1's update, even though nobody
>> else would. This won't help if #2 dies too, but it's better than nothing.
>
>
> AFAIK, no. Timestamps are inherently unreliable, as anyone can set their
> system clock (and many people/systems manage not to, possibly via no fault
> of their own e.g. a misconfigured LAN time server).
>
> --
> ----- stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
>
> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
[email protected], http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
