On Wed, Sep 17, 2008 at 12:18:46AM +0530, Sriram Narayanan wrote: > On Tue, Sep 16, 2008 at 10:03 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > The client is not going to become lightweight; your CPU processing > > estimate is not accurate (nor realistic, if one thinks about scale). > > In fact, the client is doing the bulk of the work--the server is only > > handling our HTTP/1.0 workaround and the search operation. > > I believe that Moinak's thoughts are : if the search operation is > pushed to the client (like, say, with rpm/apt), then the server would > become http, file, ftp, etc without needing a custom server behind > those services.
The client would have to keep a copy of the catalog + local indexes and sync the catalog / update its indexes every time it talks to the repo. Whereas if the server can do the searches, and if the results can be cached... OTOH, the system can probably be more secure if catalog diffs can be downloaded over HTTPS, though the diffs still have to be computed on the server side (at least the diffs can be cached). > Now if a depot server were to become mandatory, this would become a > problem when seeking mirroring hosts > > Yes, one may say that convincing mirror hosts to run custom servers > would be Belenix's headache, but given that we've always given to and > taken from the various opensolaris technologies, we see it to > everyone's advantage if we had a discussion first before going > elsewhere :) Perhaps the search and the data can be separated. > >> However the approach of naming files in the repo as hashes instead of > >> the > >> actual filenames is confusing. One cannot figure out what is what > >> without > >> cross-checking with the manifest. > > > > I suppose we'll have to disagree on the importance of this point. > > I am a sysadmin, and this is a vital functionality for me. > > If, for whatever reason, the manifests get corrupt, then I'd like to > have a mechanism to repair the manifests, as well as to skip repairing > the repairing and directly go pick up files that I need. So when a UFS filesystem gets corrupted you break out fsdb? Or do you try fsck first, then restore from backups? (Trick question, I know, since IIRC fsdb doesn't cope well with very large filesystems.) IMO you're asking for the equivalent of fsdb instead of the equivalent of fsck. IMO, given ease-of-mirroring neither is needed. Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
