Hi Shawn, On Wed, Jul 15, 2009 at 02:57:26PM -0500, Shawn Walker wrote: > Greetings, > > Below is the first draft of a proposal for the adoption of a new catalog > format for the client and server. Substantive feedback is requested by > COB of Thursday, July 23rd 2009:
<...> > 2.1.2 Proposed Catalog Format > > To accomplish the goals listed in section 2.1, a new catalog > format will be adopted. This format will be used by the client > to store catalog data locally, regardless of the format used by > the repository (e.g. the repository only provides older catalog > format). Catalogs are not separated by locale since manifests are > not, and all data is assumed to be encodable using UTF-8. > > Catalogs using this format will be composed of the following files: > > - catalog.attrs.<name> > This file will contain a python dict structure serialized in > JSON (JavaScript Object Notation) format. The metadata within > is used to describe the catalog file and its contents using the > following attributes: > > created: > The value is an ISO-8601 formatted date in UTC time > indicating when the catalog was created. > > last-modified: > The value is an ISO-8601 formatted date in UTC time > indicating when the catalog was last updated. <...> > - updatelog.attrs.<logdate> > This file will contain a python dict structure serialized in > JSON (JavaScript Object Notation) format. The metadata within > is used to describe the updatelog file and its contents using > the following attributes: > > created: > The value is an ISO-8601 formatted date in UTC time > indicating when the updatelog was created. > > last-modified: > The value is an ISO-8601 formatted date in UTC time > indicating when the updatelog was last updated. <...> > 2.3.2 Catalog Retrieval and Update Changes > > - If a repository only offers version 0 of the catalog format, > then the client API will retrieve it, but transform and store > the catalog in version 1 format. > > - If version 1 catalog data is not available, the client api will > fallback to retrieving catalog metadata by retrieving package > manifests (as it does today). This will be transparent to > clients. I've reviewed your proposal and it looks generally acceptable to me. I was wondering if you would clarify some items from 2.1.2 and 2.3.2. Who sets the values for created and last-modified? My expectation is that this would be the server, but the language is vague. In the case of last-updated, it could be read to mean either when the server last updated the catalog, or the time when the client last updated its copy of the catalog (via refresh). Also, in the case where you construct a v1 catalog from v0 data, as described in 2.3.2, how do you plan to set these attributes? If you don't know the server's timezone, how do you convert its last-modified value to UTC? I would propose that prior to catalog/1, we modify the v0 catalog/updatelog to use UTC timestamps, as that could help simplify the transition. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
