On 05/22/12 16:15, Tim Foster wrote:
On 05/23/12 10:10 AM, Shawn Walker wrote:
On 05/22/12 02:29, Tim Foster wrote:
I think there's confusion here. Any time the API changes (that is, the
set of parameters passed into functions or new functions are added or
removed), we bump the version. The only difference is how the list of
compatible versions changes.
Ok. That change was in the last webrev.
...
src/modules/client/publisher.py:
...
lines 613, 630, 658, 674, 723, 739, 767, 784:
These functions have had their operating semantics changed
incompatibly; previously, they would match solely on the URI.
hmm...
Now objects have to match both on proxy and URI. That's not
right. If I call remove_origin() with a single URI, then it
should remove any origins with that URI regardless of proxy.
Look at __eq__ and __ne__ in RepositoryURI.
I disagree. It's not that the semantics have changed, it's that the
identifying features of an origin/mirror have changed.
This is not a compatible change; the removal functions no longer remove
an origin if you don't also specify a matching proxy; that seems wrong.
They no longer remove a proxied-origin.
(which btw. didn't exist before: the system-repository used to maintain
a list of which origins to proxy, and which to contact directly - it
always used the same proxy for every origin)
Before now, all we needed to identify an origin was its URI, because
that's the only property it had. (since ssl keys/certs are publisher
properties at present, rather than origin properties)
With that in mind, I can't imagine why I'd want to have both a proxied
and un-proxied version of an origin as a user. Whether we need to do
that for the system repository seems irrelevant to the user, and I think
this significantly complicates our interface.
It's nothing to do with the system repository. By allowing multiple URIs
with different proxy values, the transport gets to choose the optimum
route to a repository - either directly, or via the proxy.
The intent here was, that say we had a custom proxy cache that had
cached some, (but perhaps not all) content, that we could take advantage
of that cache, but ultimately allow us to fall back to the direct route
if the cache itself had a slower route to the repository than we did,
for whatever reason.
The API and user interface both need to continue to work as they used to
here; if you specify an origin to remove, then remove the matching
origin. It also shouldn't be possible to have both a proxied and
unproxied version of the same origin.
Please rework this.
Groan.
Could I get a 2nd opinion please? I'll rework this if there's consensus,
but I spent a lot of time trying to get origins identified by more than
just their URI. In some places we were using the objects, other places
we were using just the string, it was pretty ugly imho, and I've got it
in a much better state now.
I've asked Danek to respond to this, but here's my primary issue:
* I don't believe that most users are going to want to manage multiple
versions of the same origin
That is, I don't believe it's useful to support multiple proxies for a
single origin, and even if we can, I don't think the user wants to
manage each one of those as separate origins.
The same goes for Key/Cert pairs.
I believe that when a user asks us to remove an origin without
qualifying it; they mean just that -- remove the origin and any references.
If they want to remove just a specific proxy or key/cert pair, then they
should specify the origin and the specific proxy or key/cert pair.
I believe that in the user's mind, the origin only exists once; the
additional things are just that -- additional configuration for that
specific origin.
With that in mind, I also don't think we should present the same origin
multiple times to the user in the output of 'pkg publisher'. I think
that would be very confusing.
To the user, they've told us where we can get packages, and how to reach
them. Viewing it as a "transport-path pair" seems very developer-centric.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
