On Tue, Dec 18, 2012 at 07:18:04PM +0200, Zeeshan Ali (Khattak) wrote: > On Tue, Dec 18, 2012 at 6:43 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > > 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 Are you saying the OsinfoInstallScript/OsinfoInstallConfig/ OsinfoInstallConfigParam relationship was intentionally designed this way? Ie OsinfoInstallConfigParam and OsinfoInstallConfig are separate on purpose? Until now my feeling was that this ended up being implemented this way, but that this was not a conscious decision, especially as this code didn't land very long ago. > 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. I'm not exactly sure what API you have in mind exactly. All I'm suggesting is gradual improvement and having a clear idea of what belongs where. I don't think we have things to deprecate to achieve that. > While I might agree with you that the 2nd approach is better, I don't > think its worth it to change towards that now. Once again, I'm a bit confused what there is to change here, nor where the big changes are. The only change I'm suggesting is having an (optional) OsinfoInstallConfigParamList be part of OsinfoInstallConfig, and use that if we later need parameter validation, ... This also means recommending the use of osinfo_install_config_new_for_script(), but even using that new method is not required, things will still work fine when using osinfo_install_config_new(). Please be more concrete as to why this is such an invasive unwanted change. Christophe
Attachment:
pgpL9mhXphPt8.pgp
Description: PGP signature
_______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
