[Zope3-dev] ZConfig schema extensibility q's

[Fred L. Drake, Jr.]

Phillip J. Eby writes:
 > Whaaaa???  I've never used the null datatype for the schema, and I can't 
 > imagine ever wanting to.  But if I did, why couldn't I just say 
 > datatype="null" or datatype="ZConfig.sometype"?

Interesting.  Zope itself doesn't use "null" either, so maybe my
expectation here is just wrong.  I generally see the top-level
configuration as a bag of stuff, but it's not so unreasonable to
disagree.

 > I'm baffled here.  If you're *not* extending another schema, of course no 
 > datatype is no datatype.  If you *are* extending a schema, then no datatype 
 > means inherit the datatype.  I don't understand why you find this 
 > confusing.  It's no different, IMO, than the code:

It depends very heavily on what your "base" datatype does.  Given that
something can be written which is usable the way you describe, it
should be fine to allow that to be "inherited".  Ok, I'll back off on
this one.

 > If you need to be able to turn a datatype *back* into a null in an extended 
 > schema, why not just have some datatype like "ZConfig-Section" available as 
 > a standard datatype?  Then you say, "if no datatype is defined or 
 > inherited, the default datatype is ZConfig-Section".

That's currently spelled "null", so that option remains available.

 > In PEAK, there is a base schema that's intended to be used for creating 
 > event-driven applications (that use a Twisted reactor or PEAK's 
 > mini-reactor).  It defines some top-level parameters to control the 
 > application as a whole, and expects to have sections included that 
 > implement certain abstract types for event-driven components.

Do you expect the "typical" extension to simply define (or import)
concrete section types that correspond to the abstract types defined
by the base schema?

If so, I'd be inclined to just use something like %import and let the
application be defined by the set of extensions imported.

 > (Btw, in case you're wondering what 'pkgfile' is, it's a PEAK-defined URL 
 > scheme for files in Python packages; PEAK uses resource loader subclasses 
 > that use PEAK's URL retrieval system (which calls down to urllib for most 
 > of the schemes that ZConfig files would use.)

Cool.  I played around with custom URI schemes as well, but that was
before the current organization of loaders and resources was fully
baked.

 > Hm.  That would work, too, as it would mean no need to even extend a schema 
 > just to hack some section types in.  On the downside, it unnecessarily 
 > exposes an implementation detail to the *end user* of the config file, 
 > who's now required to put the %import in there.  If the end user is the one 
 > doing the extending, it's great, but for my situation, the person who 
 > created the extension should take care of this.

I think using something like my propsed %import makes sense if you
want to support 3rd-party extensions that the main application can use
but doesn't know about directly.

 > I can definitely see the benefit of %import for using an existing 
 > application's schema, to extend the application with custom code.  But, 
 > that's not my use case, which is to allow extending the application itself, 
 > thus creating a new application, which is then given to an end user to 
 > configure.

That is a distinctly different case, and it makes sense to extend the
schema for this.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation