[Libosinfo] [PATCHv4 06/11] Add OsinfoInstallConfig:config-params property

[Zeeshan Ali (Khattak)]

On Tue, Dec 18, 2012 at 6:43 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> On Tue, Dec 18, 2012 at 04:47:53PM +0200, Zeeshan Ali (Khattak) wrote:
>> On Tue, Dec 18, 2012 at 12:29 PM, Christophe Fergeau
>> <cfergeau at redhat.com> wrote:
>> > Thinking a bit more about this, if we make these private then it's better
>> > to make osinfo_install_config_new_for_script public and to advocate using
>> > it instead of osinfo_install_config_new, otherwise it's pretty weird to
>> > have this config-params property which will always be NULL as far as
>> > the library user can see.
>>
>> Or we don't expose config-params as property? We can just have the
>> getter/setter for now. Also, wasn't there a way to make properties
>> private?
>
> As said that email I linked to, I think the config-params property is
> useful to have on an OsinfoInstallConfig object to be able to answer
> questions such as 'which properties should I set on this object?'.
> Currently in order to know that, you need to query the OsinfoInstallScript
> that you are going to use, which is weird and inconvenient imo.
> Basically there are 2 competing approaches:
> - OsinfoInstallConfig is just a simple wrapper on top of OsinfoEntity and
>   has dedicated getters/setters for various properties that make sense for
>   an OS installation script. However, only OsinfoInstallScript knows which
>   parameters are needed, what their value is, ... and you have to use this
>   for any validation/transformation/... you want to apply to these config
>   values
> - the second approach is to make OsinfoInstallConfig something more
>   sophisticated which knows more about the paramaters it's holding, what
>   they should be, the restrictions on their values, how to transform them,
>   ...
>
> In my opinion, the second approach is more convenient both for the library
> user and for us from a maintainance point of view, which explains my
> insistance on moving this way ;)

Thanks for the summary. Thing is that we have already moved a lot
towards the first approach and to be able to move towards the second
approach, we must deprecate the API that are designed for the first
(existing) approach. Otherwise we'll just be confusing app developers
with this contradiction.

While I might agree with you that the 2nd approach is better, I don't
think its worth it to change towards that now.

Since we both disagree about the approach, I'd like to get input from
Daniel about this too. Daniel?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124