"Peter Donald (by way of Peter Donald )" wrote: > > Hi, > > I guess we are at an impass regarding config et al thread so perhaps it > would be best to just put it up to vote. There are three aspects to this > decision.
We need a decision asap to be able to move on that means vetos are not allowed. we'll make a plain sum and follow the +s. And I'd like to place a deadline in 2 days from now. So please vote! :-) > > 1. Should Configuration allowed to be semi-structured? -1 > 2. When should validation occur? a -1 b -1 c +1 d -1 > 3. Should validation be context sensitive? -1 comments inlined below. > > Semi-structured Configuration > ----------------------------- > > I say this is a very desirable attribute. The reason is that it integrates > well with existing practices and it allows avalon integration into a larger > body of work. For a public example of how this would be useful you can have > a look at the Ant2.0 proposal Myrmidon that uses the Avalon api. > > Many existing products also use semi structured configurations which could > be a bad practice (thought I don't think so) but as such if we want to ease > development under Avalon apis then it would be desirable to allow this. > > Fedes concern is that allowing semi-structured Configuration inside Blocks > is bad practice because it leads to difficulty in parsing and validating > config data by external service. This is largely true. I can see your desire for flexibility but I stand on my point. Configuration and validation must be guarantee to be as clean as possible. I belive in this concern flexibility is very dangerous in the long run. > > 2. When should validation occur? > -------------------------------- > > In most cases I think it is agreed the answer is "as early as possible". > How should we react to config violations? I think that should be up to a > particular policy. Some people wand to fail fast and hard while others will > just remove elmenets and warn user etc. > > The problem occurs when we have hierarchies of components defined in one > config file. At each container-child level it is largely impossible to > determine how to validate if the child configuration is pluggable. > Suggested solutions so far > > a. place a xsd:schema="foo.xsd" (or whatever) in config file don't love it for your same reasons. > b. not validate child components of course this is not desirable. Thou validation shouldn't be mandatory. It's jusr recomanded. > c. not allow child components in container config This is by far the best option. separated conf file for the container and its child enable much better pluggability, easier deployment, validation, separation of concerns. > d. allow container to validate child components Add unedeed complexity to the container and is against option c wich is my favourite. > > I am -1 on (a) because it mixes concerns. (b) is default if no other action > is taken. I am +1 on either of (c) or (d) however both require significant > extra work. > > 3. Should validation be context sensitive? > ------------------------------------------ > > The more I think about this the more I begin thinking no. Context > sensitivity while nice is too much work in the general case. > God bless you! I made it! I can't belive you change your mind... what happend? :-) Anyway if we go with option (c) the problem disappear. If we go with option (d) then is up to the container to do whatever it wants. I just don't think we shouldn't provide any pre designed pattern since context sensitive validation is too specific to the container. > So we have two things to decide. How we handle Configuration validation in > general and how we handle it specifically in the phoenix kernel. Perhaps to > serve all parties we could to do the following. > > * Allow only one validator for each top-level block and either implement 2b > or 2c > * Allow semi structured data. (for non-phoenix users of avalonapi). > * disallow context sensitive (ie external) validation disallow? We can't prevent it... just not enforce it. > > Naturally I am +1 on all the above ;) > > Cheers, > > Pete
