So, I think you *do* need conversion code specific to state -- the methods exported from state should be in terms of the storage types, because they're the language we've chosen to model storage, so there needs to be conversion code in state (or possibly in an internal package -- but either way there's no reason to expose it to anyone else).
WRT params, though, we already have two groups of client packages, so the same forces don't quite apply: and I still prefer that we *not* import other packages into params [0]. How about a single params/convert package? Cheers William [0] this is because the temptation to use a storage.Foo in place of a params.Foo has historically been overwhelming (and while it's *very dangerous* to do that it's hard to make the danger sufficiently obvious to dissuade distracted devs from doing so). On Tue, Feb 10, 2015 at 11:07 AM, Andrew Wilkins <[email protected]> wrote: > Hi all, > > Anastasia raised an issue in http://reviews.vapour.ws/r/885/ about how to > cut down on struct conversions between params, state, and domain packages. > In this case we're talking about storage. The following API server facades > currently participate in storage: > - client > - storage > - provisioner > - diskmanager (to be renamed, this lists block devices on machines) > - diskformatter > - storageworker (to be renamed, this is the dynamic storage provisioner) > > Each facade have some overlap in dealing with storage entities, e.g. the > diskformatter and diskmanager each need to deal with block devices. This > leads to much duplication of struct copying/conversion code when toing and > froing between state and clients. > > I don't want to go adding conversion code to the params, state or storage > packages, as they really shouldn't have dependencies on each other. Does > anyone have a good idea about where to put this common functionality? Maybe > "api/common/storage", "apiserver/common/storage"? Does not appeal, but I > can't think of a better option. > > Cheers, > Andrew > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
