On Tue, May 18, 2010 at 04:20:12PM -0500, Shawn Walker wrote:
> Realistically, I don't expect this to be used that often.  For
> optimal access to the archive, there should really only be one index
> file (especially if you were performing remote, selective
> extraction).

I have to confess that there's not much of a use case for this type of
transport access.  Remote selective extraction is essentially what we
have now through the file/0 interface.  In situations where we want to
reduce the transport latency, we either need to make fewer requests, or
more requests in parallel.  The first part of this work will be to
multi-thread the transport.  The second part is to download entire
archives if enough files have changed between the N and N+1 version of
the package.

You can allow this type of access to be possible, but I don't think
we'll actually want to enable it in the client.

> >>     5.4. Client and Depot Support for On-Disk Archive Format:
> >>
> >>         The pkg.server.repository module will be updated to support
> >>         the serving of a repository in readonly mode using a pkg(5)
> >>         archive file.
> >>
> >>         The pkg.client.api transport system will be updated to support
> >>         the usage of a pkg(5) archive file as an origin for package
> >>         data.  When multiple origins are present for a publisher, they
> >>         will be checked in this order of preference for package data:
> >>
> >>         - local client cache
> >>         - pkg(5) archive files
> >>         - remaining origins and mirrors
> >
> >I'm okay with specifying that the local client cache is accessed first;
> >however, I don't think it's appropriate to define the order in which any
> >mirrors and origins will be accessed.  This should be handled by the
> >quality measurement system in the transport.
> 
> This is really talking about what happens with _action_cached() so,
> at the moment, is actually no different from what's in the gate
> (except the archive files bit).

That seems like an implementation detal that should be omitted.  I don't
have a problem with specifying that we'll look in the local cache first.
However, what exactly constitutes a local cache, and the order of access of
transport endpoints is too specific for this proposal.

Thanks,

-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to