On Wed, Apr 7, 2010 at 1:58 PM, Dmitri Pal <d...@redhat.com> wrote: > >>> No, we absolutely need to have the ability for third-party backends to >>> have their own completely self-sufficient configuration. >>> >>> >> >> Then we will just not have it at all for now. >> Sorry. I can't commit to doing something of this complexity >> in a reasonable time. >> >> > After some more thinking and a bit of cooling. > We do not add the ability to handle the 3rd party back end day one. > Why? One of the reasons - it is a too big task to chew. > We have a plan how to get there. Slowly! > We tries several time though I asked for it to be thought through day one. > It was not and thus we had more things to change. > > Here we can think about it as a design goal and even spec it a bit > but delay the actual implementation. > Why we have to deliver the config validation complexity day one? > Why can't follow the same steps as with actual back ends? > > The whole packaging guidelines seems like a dark magic in this case. > Anyone can edit a config file: an admin manually, a puppet manifest > automatically, etc. > > I do not see how the schema file is different in this case and > why it can't be edited in the same way by different sources. > What you are saying really seems as an artificial requirement for v1. > Please example how shcema file is different from any config file that > anyone can edit?
And what is wrong with a a .d directory like every other piece of 'nix software in existence? The sssd.api.d directory seems like the proper way whereas 1 big schema file is a step backwards. For 1 it would be breaking both Debian Policy and Fedora Packaging Guidelines. Additionally, it would make it for difficult for 3rd party backends to integrate. -- Jeff Schroeder Don't drink and derive, alcohol and analysis don't mix. http://www.digitalprognosis.com _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
