[AFS3-std] is the CellServDB file format a standard?

[Jeffrey Hutzelman]

--On Monday, December 13, 2010 01:43:44 PM -0500 Jeffrey Altman 
<jaltman@your-file-system.com> 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