Comments on Dflat v. 0.16
Erik Hetzner
Here are my comments from a close read of D-flat. They are pretty
boring and nitpicky, but hopefully should be useful.
I also have some more fundamental ideas about how Dflat could be
reworked to make it more generally compatible with versioning systems
like git, hg, or darcs. I cannot see, currently, how Dflat could be
made to work with any of these versioning systems.
General
=======
I think it would be a good idea to reserve all files and directories
(except inside versions) that begin with ``dflat-`` for the future use
of later versions of Dflat specs.
§3
===
Namaste signature file is OPTIONAL here, but RECOMMENDED in §3.1.
§3.1
~~~~
Namaste tags are LF terminated (per Namaste spec), but the text reads
“contents of the file MUST exactly duplicate the file name.” The
production rules allow CR or CRLF or LF, but Namaste requires
the newline.
§3.2
~~~~
What does File-count mean? Which files? Versioned files? All files?
What about files deleted between versions, or added, etc?
§3.4
~~~~
In the interests of interoperability it would seem that the
``dflat-info.txt`` file should be REQUIRED, not RECOMMENDED.
I think ``Object-scheme`` would be better named ``Dflat-scheme``.
Would we really find a non-Dflat object scheme in a ``dflat-info.txt``
file?
§3.5
~~~~
The ``lock.txt`` file is described as “OPTIONAL”, but “a process
intending to manipulate a Dflat in a manner that affects the state of
its home directory MUST first obtain a write lock on that directory.”
I don’t understand how to reconcile this.
“if [the ``lock.txt`` file is] present the process SHOULD continue
only under an assumption that the data read may be incomplete or
inconsistent.” I don’t think the word SHOULD (per RFC 2119) is best
used here. How could a system choose to ignore this item?
§3.6
~~~~
Could ``last-access.txt`` and ``last-fixity.txt`` be combined to
single file, named, e.g., ``timestamps.txt``, with the content::
Last-access: 2209-01-29T05:33:24+0800 66212
Last-fixity: 2008-12-22T23:00:10+0800 18002
While marginally more difficult to process, it seems to me that this
could greatly reduce clutter and add to extensibility. This would also
make it similar to the ``summary-stats.txt`` file described in §3.2.
Regarding ``summary-stats.txt``, it is not clear to me why this info
is stored in files under the ``log/`` but other, similar, info is
stored in ``admin/summary-stats.txt``. Could these files be combined?
If a file has not been fixity checked, what is the value of
Last-fixity? How do we distinguish between no fixity check done and
the fixity check not being recorded?
The semantics of a ``lock.txt`` file in the ``log`` directory are not
defined.
§3.7.1
~~~~~~
The ``empty.txt`` file contains the string ``empty`` (no ``.txt``).
The ``0=dflat_0.16`` file contains the text ``0=dflat_0.16`` (with a
LF, per Namaste spec). Would it be better to establish a more standard
relationship between file names and contents in these similar types of
files?
§3.7.2
~~~~~~
“The complete set of files and directories that make up the
representation SHOULD be listed in the OPTIONAL…” SHOULD/RECOMMENDED
or MAY/OPTIONAL?
§3.7.3
~~~~~~
“The complete set of files and directories that make up the
representation SHOULD be listed in the OPTIONAL …” SHOULD/RECOMMENDED
or MAY/OPTIONAL?
§4
~~~
Why MUST a Dnatural directory contain a Namaste signature but a Dflat
only MAY or SHOULD (see §3 above).
§5
~~~
Regarding ``no-change.txt``, see my question about ``empty.txt``
above.
-Erik