[email protected] wrote:
On Wed, Jul 15, 2009 at 02:57:26PM -0500, Shawn Walker wrote:
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).
A key requirement of this new format (/catalog/1/) is that the client
maintains *unmodified* copies of both the attrs and catalog files. That
is, they should be bit-for-bit identical to whatever the server has
(although how incremental updates will work with signed catalogs will be
a fascinating discussion at a later point).
In short, that means that the 'created' and 'last-modified' fields are
set by the repository when it creates the catalog. So, if the
repository offers /catalog/1/ that means that it will be doing a simple
GET to retrieve the attrs/catalog files and store them on disk.
If we need the client to store its own information about the catalogs,
then an auxiliary file will need to be proposed and implemented.
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.
Changing the current catalog/0 would still leave me with older depot
servers that don't use UTC timestamps, so doesn't seem completely useful
and would just possibly break older clients since older clients also
store the server's last modified date as is and use that for comparison
with the depot server. Don't forget the updatelog currently stores
entries in server local time as well.
I was actually just going to store the repository's /catalog/0/
last-modified stamp and treat it as UTC, and then use the last modified
date as the created date the first time the transformed catalog is written.
Since I don't use the client's local time for last-modified comparisons
(I use the last-modified time as-is from the attrs file), that should
work for both the version 0 and version 1 catalog case.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
