Descriptionstate/apiserver/common: Registry tracks types
This changes the Facades registry so that instead of just tracking the
FacadeFactory functions, it also explicitly tracks the Facade type
itself. The main benefit from doing this is that we have a proper (and
passing) TestDiscardedAPIMethods that allows us to introspect everything
we are exposing over the API without having to actually instantiate any
of those objects.
While the only specific win today is the test case, the wins for the
longer term are:
1) The ability to walk the whole API and determine all Facade versions
along with all methods that are available.
2) If we so choose, we can restore the "introspect a Root object"
(rpc.Serve vs the new rpc.ServeCaller) and have it go back to doing
exactly what it did with hardcoded types per exposed facade. That was
more code right now, which meant delaying getting API versioning out
there.
3) It helps enforce the norm that (Facade, version) describes exactly 1
type, so we don't accidently do weird things and return variable APIs
based on the "id" of requests.
I don't yet have code that ensures the objects being returned by the
factory exactly match the Type that they've been registered with. It
didn't seem to be a big win given that most places use
RegisterStandardFacade that explicitly does the registration by
inferring the type from the function that is handed in.
However, "RegisterFacade(Factory, Type)" does define Factory as
returning interface{} and Type as whatever you want. So if we want a bit
more rigidity, we could add that here.
https://code.launchpad.net/~jameinel/juju-core/api-registry-tracks-type/+merge/220588
Requires: https://code.launchpad.net/~jameinel/juju-core/api-use-register-standard-facade/+merge/219670
(do not edit description out of merge proposal)
Patch Set 1 #
Total comments: 8
Patch Set 2 : state/apiserver/common: Registry tracks types #
MessagesTotal messages: 3
|