Hi Brock,

I'm just looking at the transport parts for now.

On Wed, Aug 04, 2010 at 09:25:18PM -0700, Brock Pytlik wrote:
> Greetings all,
> 
> Here's the webrev for the manifest signing changes:
> http://cr.opensolaris.org/~bpytlik/ips-11611-v4/
> 
> Transport has been changed to merge with the other recent changes to
> transport.

The client-side stuff you've added looks good.  I hope the changes to
add the file-path were pretty straight-forward.

Now that I've changed __gen_repo() you actually now have the ability to
enable repo.get_datastream() and repo.get_files() to use either file/0,
or file/1, depending upon which version is available.  If you tell
__gen_repo to return origins that support either [0, 1] and pass the
version number as an argument to get_datastream and get_files, these
methods should just work, since file/1 and file/0 are equivalent for
GET.

On the depot side, I have some additional concerns about file/1.  In
particular, we enable certain operations based upon what mode the depot
is in.  There's a map for everything, a map for read-only, and a map for
mirror mode.  In the case of POST file/1, it looks like this operation
is enabled even if the depot is in readonly or mirror mode.  At a
minimum, we need to make sure that you can't POST a file in these modes.
I'm also a bit concerned about how we determine whether POST for file/1
is enabled by the client.  Up to this point, the versions/0 information
tells us whether the depot supports a particular operation, and what
versions are supported.  If a depot isn't providing a particular
operation, the operation string is absent in the versions/0 information.
However, with file/1, we can support GET file/1, but not POST file/1.
The versions/0 information doesn't currently have a way of expressing
this.  Shawn may not agree with me, but perhaps add_cert, or whatever
you had before, is actually preferable?  Thoughts?

Thanks,

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

Reply via email to