The plan is to still support multiple roots, so the registry would be root
specific. So multiple potential registries and the current one gets handed
to the RPC package from the Root object.



On Fri, May 9, 2014 at 12:18 AM, Roger Peppe <email address hidden>wrote:

> I am not convinced a global name space for types is a good idea.  It should
> be possible for two separate modules within the same program to export
> entirely separate APIs without risk of clashing. I am on holiday though.  I
> will follow this no more!
> On 8 May 2014 15:15, "John A Meinel" <email address hidden> wrote:
>
> > FWIW I plan on going further to introduce a runtime registry so that as
> > types are declared they are registered with what version is available,
> etc.
> > And while it doesn't let you use static introspection, I think it
> provides
> > the same dynamic introspection.
> > I think it also allows for less coupling and repeating yourself. (Types
> can
> > register themselves in an init() hook rather that having to have a
> concrete
> > root type that has lots of:
> > func (r *srvRoot) Machiner(id string) (*machine.MachinerAPI, error) {
> > if id != "" {
> > // Safeguard id for possible future use.
> > return nil, common.ErrBadId
> > }
> > return machine.NewMachinerAPI(r.srv.state, r.resources, r)
> > }
> >
> > redundancy.
> >
> >
> >
> > On Thu, May 8, 2014 at 1:54 PM, Roger Peppe <<email address hidden>
> > >wrote:
> >
> > > I realise this is the direction you have decided to go, but before you
> > do,
> > > I think it is worth considering the advantages that a strictly static
> set
> > > of exported methods provides.  Specifically it allows the possibility
> of
> > > allowing clients to introspect rpc method types without invoking the
> > > methods, and other code to see all the methods exported, for example to
> > > automatically generate documentation for the entire API or to generate
> > > client entry points similarly (both of which I have done in the past).
> > >
> > > I personally think that it is a pity we are to lose these
> possibilities,
> > > when there is a reasonable versioning alternative available (we could
> > just
> > > include the version number in the top level method names).
> > > On 8 May 2014 12:36, "John A Meinel" <email address hidden> wrote:
> > >
> > > > Reviewers: mp+218764_code.launchpad.net,
> > > >
> > > > Message:
> > > > Please take a look.
> > > >
> > > > Description:
> > > > rpc: expose concrete types
> > > >
> > > > This changes the RPC package a bit so that if you are declaring
> > > > RootMethod that returns 'interface{}' it can find the concrete type
> > that
> > > > is being returned and expose the methods on that type (instead of
> > > > exposing 0 methods from interface{}).
> > > >
> > > > This is a step along the way to supporting passing versions for
> Facades
> > > > in the "id" slot. We currently let you pass the value, but the
> concrete
> > > > type that is returned defines all of the Methods that could be
> > > > available. Which means that if you add a new Method in V2 of your
> API,
> > > > you would suddenly have that exposed in the V1 of your API. Similarly
> > > > you couldn't *actually* ever change the interface for a give method,
> > > > because then you couldn't call it one way for V1 and a different way
> > for
> > > > V2.
> > > >
> > > > There is a fair bit more to be done before we have actual API
> > > > versioning, but this is a step along that path and it seemed cohesive
> > > > enough to review on its own.
> > > >
> > > >
> > > >
> > >
> >
> https://code.launchpad.net/~jameinel/juju-core/reflect-only-facades/+merge/218764
> > > >
> > > > (do not edit description out of merge proposal)
> > > >
> > > >
> > > > Please review this at https://codereview.appspot.com/98090043/
> > > >
> > > > Affected files (+290, -61 lines):
> > > >    A [revision details]
> > > >    M rpc/reflect_test.go
> > > >    M rpc/rpc_test.go
> > > >    M rpc/rpcreflect/type.go
> > > >    M rpc/rpcreflect/value.go
> > > >    M rpc/server.go
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > >
> > >
> >
> https://code.launchpad.net/~jameinel/juju-core/reflect-only-facades/+merge/218764
> > > > Your team juju hackers is requested to review the proposed merge of
> > > > lp:~jameinel/juju-core/reflect-only-facades into lp:juju-core.
> > > >
> > >
> > > --
> > >
> > >
> >
> https://code.launchpad.net/~jameinel/juju-core/reflect-only-facades/+merge/218764
> > > You are the owner of lp:~jameinel/juju-core/reflect-only-facades.
> > >
> >
> > --
> >
> >
> https://code.launchpad.net/~jameinel/juju-core/reflect-only-facades/+merge/218764
> > Your team juju hackers is requested to review the proposed merge of
> > lp:~jameinel/juju-core/reflect-only-facades into lp:juju-core.
> >
>
> --
>
> https://code.launchpad.net/~jameinel/juju-core/reflect-only-facades/+merge/218764
> You are the owner of lp:~jameinel/juju-core/reflect-only-facades.
>