GoogleCloudPlatform/kubernetes — pull request #742 by smarterclayton (2014-08-02 18:46:18+00:00)
Title: Thought Experiment - Separate API object space completely

Removes the singleton for API KnownTypes. Not complete, mostly because the Watch deserialization mechanism depends on static access, and also because of the etcd_tools dependency on deserialization.

I wanted to play around with the question: can the implicit API type singleton factory (and global namespace of api types) be split in a way that allows easier reuse:

* The actual api/ change works quite well as an Interface - if you treated a package containing types as an implementation of Interface, you can easily expose both types as a package as well as something to pass around to generic decoders/encoding
* APIServer today is dependent on api.Status (belongs to the base API) so if you wanted to have multiple separate RESTStorage objects coming from different type implementations you need to split api.Status into its own type, which means clients can't use a single decoding library across all types
* The watch function is also dependent on a singleton type registry for decoding the APIObject coming back in a stream.
* APIServer allows multiple RESTStorage resources which in theory can encode/decode independent types, but watch, operations, and api.Status are dependent on the base API and so would have to be cloned or split

Open questions (@lavalamp @erictune):
* Is a singleton global type registry bad, good, or neutral?
* Opinion: Would prefer the global registry be something created and passed in to an APIserver as a serializer interface or underneath, and that the set of registered types is also defined at point of use (apiserver, client) via an explicit operation. I.e. `api.NewScheme(pods.Types, controllers.Types, services.Types)` and get rid of `AddKnownTypes`
* Should api.Status, Watch, and Operations be part of apiserver? Do they need to be versioned?
* Opinion: they're only weakly coupled with what's in api/, they should be "owned" by the apiserver package and the generic API client. A client should be able to get them by `api.NewScheme(apiserver.Types, pods.Types, ... // other types I want)
* Should apiserver depend on "the api pkg + types", "the api pkg w/o types", or "only a RESTStorage/WatchStorage implementation"
* Opinion: apiserver should not depend on types outside of its package, and preferably everything else should be an interface passed with RESTStorage / WatchStorage. Watch should take a "Scheme"
* Operations is already something that won't work behind a load balancer as is - should this be moved soon to an OperationStorage abstraction?
* No opinion