Hi all,
On 05/30/12 11:58 AM, Shawn Walker wrote:
It is believed that this is the desired model instead:
Publisher
.repository
Repository
.origins
RepositoryURI
.uri = http://example.com
.proxies = [
ProxyURI (new object)
.uri = http://proxy2
]
I've changed the previous granular proxy implementation to use this
model now, and believe that what we've got now is better - thanks for
the suggestion Shawn.
To accommodate the above, the changes to the various remove_* and
update_* methods of pkg.client.publisher.Repository should be reverted.
(The .update_* methods are completely unused, I would go ahead and
update their docstrings to mark them as deprecated and then add a note
to client_api_versions.txt when doing so; we should remove them in the
future once we verify no other consumers are using them.)
I've done that.
As for the pkg.client.publisher.Repository add_* methods, I have a few
suggestions for possible (different) implementations:
3) revert the changes to the add_* methods; require API consumers to
simply provide complete RepositoryURI objects with appropriate
ProxyURI objects assigned already. Trying to squeeze a tiered
object structure info a flat set of parameters leads to tears
anyway.
I went with this one, ultimately.
However, while the proposed data model above allows for multiple proxies
per-origin, it is believed that until we find resolutions for some of
the various transport issues that are currently open, we should not
allow multiple proxies for the same origin (although the data model can
prepare for that possibility internally). So there should be some sort
of exception raised if an attempt to have more than one for a single
origin is made.
I've done this too.
To make the above changes work with the rest of what you have, I would
then suggest you create a ProxiedURI object that inherits from
RepositoryURI and adds the .proxy, .runtime_proxy, and .key propeties
that you can use in the various transport modules.
pkg.client.transport __gen_repo can be changed to yield ProxiedURI
objects instead of yielding the normal RepositoryURI objects; these can
be created on the fly (and cached if necessary, although I don't think
it will be).
I called the class TransportRepoURI, rather than ProxiedURI, to allow it
to fit with other origin-level properties we may want to add in the
future. I did check to see whether caching the objects was worthwhile,
and it actually turned out to be faster to create the objects each time
than it was to cache them, but there wasn't much in the difference
either way.
There's a few parts of the implementation I'm not wild about (like the
way we override parts of RepositoryURI) but see what you think.
I've got a webrev at:
https://cr.opensolaris.org/action/browse/pkg/timf/granular-proxies-4/
For convenience, I've also included an incremental webrev against the
previous granular-proxy bits I posted. It's not a perfect incremental
webrev, as it contains a few changesets that weren't in the previous
granular-proxy wad, but it may be helpful in terms of which parts of
this wad to concentrate on, given the previous reviews.
Finally, please note that Danek really only had feedback about the data
model (that is, the structure of the objects internally); the specific
implementation suggestions here are largely my own. They likely need
further vetting before implementation.
No worries, they were definitely helpful. Along the way, there were some
subtle system publisher interactions involved that took some time to get
right, but the tests all pass now :-)
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
