Branko Čibej <brane@xbc.nu> writes:
> I'm a bit uneasy about one thing: in the "strings" table, there's no way to
> distinguist between a PROPLIST and file contents. This means we can't
> (consistently) check that a STRING-KEY refers to the right kind of
> data. Do we
> want to have such sanity checks? If yes, we might have two string tables
> instead, one for PROPLISTs and one for CONTENTS.
>
> The rest seems fine.
At first, I thought: yes, it might be a good idea to use two tables:
`strings' and `skels' (or perhaps `strings' and `lists'). The second
table would hold proplists and dir-entries-skels.
Then, I thought:
There isn't in general any reliable way to distinguish between a skel
string and a non-skel string. If you happen to have a string that
looks like a skel, then if you apply some "is_skel" test to it, the
test will return true, even though maybe it just happens to be a file
contents that looks like a skel.
So no matter what we do, we'll be relying on using the right key.
Either we got the value from a `lists' table, in which case we'd
better hope we didn't accidentally store a contents string there, or
we got the value from the `strings' table, in which case we'd better
hope our key was right. (Or vice versa, you know.)
Well, if the key is wrong, then we're not *really* getting much
insurance from the fact that we're at least grabbing the value from
the right table. Correctly parsing the wrong skel is not a better
error than either a) returning a parse error because a string is not a
well-formed skel, or b) correctly parsing the wrong skel :-). And at
least in scenario (a), we'll detect the error sooner.
So we might as well just put them all in strings.
> As I mentioned before, I've been searching for articles about delta
> composition. It turns out I was a bit too optimistic about the results. It
> looks like we'll have to invent the wheel again, or at least spokes ... So,
> again, if anybody has any ideas, please yell.
I've some ideas, actually; will be committing them to fs-improvements
forthwith.
Received on Sat Oct 21 14:36:29 2006