--On Monday, December 13, 2010 01:43:44 PM -0500 Jeffrey Altman
<[email protected]> wrote:
The syntax of the CellServDB file format [1] is well-known but is it a
standard from the perspective of this group? The answer to the question
will determine where discussion of replacing the file format should take
place.
That's a good question. There is certainly precedent for things which are
not network protocols but on which some implementors have nonetheless
agreed to make an effort to be consistent. For example, pioctl()
operations.
I think I agree with Derrick that in principle, the local representation of
cell configuration data is implementation-specific. However, as maintainer
of a widely-distributed cell-configuration database, I would like to see
implementations support a single, common interchange format for this data,
so that I can publish a database which is usable across implementations and
versions. This suggests a need for a standardized, extensible format.
While it's not a strict requirement for my needs, I'd like to see such a
format be human-readable, so people can see what they're importing. I'd
also prefer for it to be reasonably easy for humans to create and edit
files in this format, so that others can easily distribute complete or
partial databases or entries for single cells. The GRAND.CENTRAL.ORG
Public CellServDB is generated mechanically from a database, but I suspect
many administrators would want to maintain this data at least partially
manually.
Also, the vast majority of new and updated entries I receive for the GCO
database arrive in the form of CellServDB entries. This makes my life
easier, because my tools are able to parse such entries and enter them into
the database. It also reduces the chance of errors, not only because I
don't have to construct an entry manually, but also because anyone
submitting an update can simply copy an entry exactly as it appears in
their own CellServDB file. I would definitely prefer to see these
properties continue to hold.
I agree with Jeff that the current CellServDB has many shortcomings, and
that development of a replacement would be appropriate.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
