On Mar 6, 2013, at 7:50 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > I think it would make a lot of sense -- not just in terms of > implementation but also for end user clarity -- to have some simple, > straightforward to understand caveats about maintaining schema > information... > > 1) If you want to keep schema information in an authoritative config file > that you can manually edit, then the /schema REST API will be read only. > > 2) If you wish to use the /schema REST API for read and write operations, > then schema information will be persisted under the covers in a data store > whose format is an implementation detail just like the index file format. > > 3) If you are using a schema config file and you wish to switch to using > the /schema REST API for managing schema information, there is a > tool/command/API you can run to so. > > 4) if you are using the /schema REST API for managing schema information, > and you wish to switch to using a schema config file, there is a > tool/command/API you can run to export the schema info if a config file > format.
+1 > ...wether of not the "under the covers in a data store" used by the REST > API is JSON, or some binary data, or an XML file just schema.xml w/o > whitespace/comments should be an implementation detail. Likewise is the > question of wether some new config file formats are added -- it shouldn't > matter. > > If it's config it's config and the user owns it. > If it's data it's data and the system owns it. Calling the system-owned file 'schema.dat', rather than 'schema.json' (i.e., extension=format), would help to reinforce this black-box view. Steve
