To add a new API call there are at least two possible
approaches.
For example, say I want to add a new API call to the Client facade.
1) (the preferred approach as I understand it)
- copy apiserver/client to apiserver/clientv1.
- change the facade implementation in clientv1 so that
it embeds the old client version, but keep all the
tests intact.
- call common.RegisterStandardFacade with the new version
in clientv1.
- implement the new call in clientv1 and add
a test for that call.
- implement the client side for the new call in api/client.go.
2) (the approach that most people have used so far)
- implement the new call in clientv1 and add a test for that call.
- implement the client side for the new call in api/client.go.
I am wondering if the former approach is enough better than
the latter to justify the costs that it imposes.
The costs I'm thinking of are:
- it grows the code significantly more and adds a significantly
larger barrier to adding new API features.
- the tests are now duplicated (not insignificant - the apiserver/client
tests take >2minutes to run on my machine).
- the resulting code is harder to understand as there's an extra
layer of indirection on every API call to clientv1 (this will
get worse as more versions are added).
One advantage that I can see to the former approach is
that it provides us with a tangibly different version number
when someone tries to use a new client against an old server,
which could result in a nicer error message in this case.
On the other hand, as long as someone keeps track of
which API calls are added in which juju version, an
error message saying "API call MyNewCall not implemented"
is probably just as useful, especially if it is printed along
with a link to more information.
Thoughts?
cheers,
rog.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
