[Config-loader] Scope of the project

[Clinton Gormley]

> I see it as a pipeline as well.
> 
> 1. Read from a source (Config::Any, Config::General, CodeRef, ...)
> 2. Merge based on weights (source importance) or custom algorithm
> 3. Filter, or postprocessing (do substitution, such as
> __path_to( ... )__ )
> 
> Right now, I'm thinking that local overrides and such should be the
> responsibility of the source. What if
> the source is a database? Path-style localization doesn't make much
> sense there.
> 
Path-style localization? Not sure what you mean by this, but the way I'm
thinking of this is as follows:

 - we load config data from various sources and merge them into a single
   hash
 - the point at which each source is merged into the hash can be 
   defined but, for instance, loading a directory tree could use dir
   and file names for nested keys, eg:

     config/
         app/
           one.conf
           two.conf
         db/
           one.conf
           two.conf
 
   could result in:
     {
        app => {
                 one => {...},
                 two => {...},
        },
        db  => {
                 one => {...},
                 two => {...},
        },
      }

When loading data from a DB, we could specify that it should be inserted
at a particular point in the hash, or even that we could load key =>
value pairs from the DB and use the $key to decide where to insert each
value, eg:

     app.one.myvar => 3

In this example, I've used a period as a level separator.  It may be
that some prefer a / but I remember Matt saying that he had tried that
and didn't like it for some reason that I don't remember.

Is this what you meant by path style localization?


>         
>         Also, re ::Simple. If my thinking is correct, the ::Simple
>         module
>         wouldn't be required, as Config::Loader would do the right
>         thing with
>         the minimum of configuration.
> 
> Take t0m's point earlier in the thread. He wants a way for people to
> easily use their Catalyst configuration outside of Catalyst.
> Let's say that the Catalyst Config::Loader config looks something like
> this:
> 
> Config::Loader->new( ... 30 lines snipped (which ENVs to grab,
> etc) ... )
> 
> Does that mean people need to recreate those 30 lines in their app if
> they want to access their Catalyst config? No, that's not very easy.
> 
> The easy way to do that would be:
> 
> # Catalyst::Config is built off of Config::Loader
> my $config = Catalyst::Config->new( name => $name, package =>
> $package ) # You're done.


Ah yes, exactly!  I was thinking thought that that would be your own
custom class, rather than Config::Loader::Simple, but maybe I'm not
seeing what your $package looks like.


>  
> That's how I see the relationship between Config::Loader and
> Config::Loader::Simple
> 
> At this point, I think Config::Loader::Simple would be a small wrapper
> around Config::Any, but I'm not really sure

I don't think making it a wrapper around Config::Any would gain us
anything. Config::Loader should already make use of Config::Any for its
default file loading (with the ability to override expected formats or
parsers)

But we can leave that until we have Config::Loader and we can see what
(if any) Simple version would be useful.

ta

clint
> 
> Rob
> 
> _______________________________________________
> Config-loader mailing list
> Config-loader at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/config-loader