On Tue, Jul 28, 2009 at 04:35:31PM -0500, Shawn Walker wrote: > Below is the second draft of a proposal for the adoption of a new > catalog format for the client and server. As this is a revision of the > first format, and I believe I have addressed all noted concerns, > substantive feedback is requested by COB of Friday, July 31st 2009.
> 2.1.2 Proposed Catalog Format <...> I like the changes you've made to the catalog format, but I still think the updatelog format can be improved. > To enable incremental catalog updates, an "updatelog" will also be > provided as a single, merged file that can be used to incrementally > update any of the catalog parts. It is composed of the following > files: > > - 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: <...> > - updatelog.<logdate> > > This file will contain a python dict structure serialized in > JSON (JavaScript Object Notation) format. It seems unnecessary to have a separate updatelog.attrs file. The attributes should probably live with all of the others in catalog.attrs, or in the updatelog.<logdate> file itself. It better to have these files be self-describing and I have some concern about the number of round-trips the client will have to make to perform the download. In the current model, the client makes one request and either gets a 304, a full catalog, or a stream of updates. In the new model, the client must download catalog.attrs before it can determine, what, if anything, needs to be subsequently downloaded. To get content, this is a minimum of two round trips, with potentially pipelined requests. If the client also has to download the attributes for the updatelog prior to performing a download of the updatelog data, we've introduced an extra trip that's going to be a pain for users on links with high latency. It would be better if we could download a single attributes file that describes all of the metadata we need to retrieve, and use that to batch up a single subsequent multiple item request (piplined). Thanks, -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
