Hmm. Pros abd cons: pro format is important, cons: i tried to minimize the api: reader:something -> the reader can be implemented in any way. The implementation can decide, if (explit) formats are supported, eg: reader:[format]foo. Therefore I moved the format part to the implementation completely...
Other opinions? Werner Keil <[email protected]> schrieb am Mi., 3. Dez. 2014 um 14:35: > What would "reader" or "format" have to to here in a fromPath() method? > That's more a "reader" or "loader" thing, some may call it "parsing" but > I'd say that only makes sense if you have a relatively small string, not > broader source. > > It may be a little bit simpler given the input format is only W3C DDR > compliant XML data, but looking at recently graduated DeviceMap, the > ".next" Java client offers a variety of "resource loaders" either from > within an archive, a URL or as file in a file system: > http://svn.apache.org/repos/asf/devicemap/trunk/devicemap/ > java/classifier/src/main/java/org/apache/devicemap/loader/ > > Reporting and output or "formatting" would be something different IMHO, not > to be mixed with loader or reader. > > Werner > > On Wed, Dec 3, 2014 at 2:24 PM, Romain Manni-Bucau <[email protected]> > wrote: > > > Hmm, there is something fishy fo rme in this reader/format/... > discussion. > > > > From your description I would expect: > > PropertyProviders.fromPath("reader[:format]whatever"); to be > > supported. And if it is what there is behind the scene I would like it > > to be part of the API. > > > > One simple use case: support properties, yaml, ini, xml or whatever > > just be called myconfig.conf or myconfig.config or any other > > extension. > > > > I agree we can guess the format from the extension often enough to not > > force its usage but since it is important as you mentionned it I think > > we need to accept it is part of the API. > > > > wdyt? > > > > > > > > Romain Manni-Bucau > > @rmannibucau > > http://www.tomitribe.com > > http://rmannibucau.wordpress.com > > https://github.com/rmannibucau > > > > > > 2014-12-03 14:02 GMT+01:00 Werner Keil <[email protected]>: > > > The Asciidoc reporting is not part of the Open Source project AFAIK, > but > > > here's Multiconf on GitHub: > > > https://github.com/lhupfeldt/multiconf > > > > > > For those familiar with scripting languages like Groovy Python should > not > > > feel too strange;-) > > > Here a quick example on how it can be used: > > > > > > # Define environments > > > > > > # Use EnvFactory() to create environment or group of environments > > > ef = EnvFactory() > > > > > > # We have five environments and we define them here > > > devlocal = ef.Env('devlocal') > > > devi = ef.Env('devi') > > > devs = ef.Env('devs') > > > preprod = ef.Env('preprod') > > > prod = ef.Env('prod') > > > > > > # Grouping environments per their roles > > > g_dev = ef.EnvGroup('g_dev', devlocal, devi, devs) > > > g_prod = ef.EnvGroup('g_prod', preprod, prod) > > > > > > > > > # This function is used to describe all environments and return an > > > instantiated environment > > > # configuration for environment with name 'env_name', which is passed > as > > > parameter > > > def conf(env_name): > > > env = ef.env(env_name) > > > > > > # This will define a weblogic configuration for all environments > > > defined above > > > # But the result of execution of conf() will be the setting for > > > environment > > > # passed as argument 'env_name' > > > # Use EnvFactory 'ef' to define the required/allowed environments > > > # The 'weblogic_config' class is defined in framework.py > > > with weblogic_config(env, ef) as dc: > > > # Set domain base port number for different environments. > > > # Domain base port is used as base to calculate port offsets > > > # Here we're saying that Weblogic in g_prod group will have > > > # attribute base_port set to 7000, and each of the development > > > environments > > > # will have unique base_port > > > dc.setattr('base_port', g_prod=7000, devi=7100, devs=7200, > > > devlocal=7300) > > > [...] > > > > > > The "DSL" for configuration is almost entirely done in Python, thus > could > > > be compared to annotated Java code where we support that. Multiconf > > > generates al sorts of files like XML (for WLS and other containers) but > > > configuration itself is barely done or overridden via XML. > > > > > > We may have a slightly broader scope but some aspects and goals are > > pretty > > > similar. > > > > > > Werner > > > > > > On Wed, Dec 3, 2014 at 1:19 PM, Tresch, Anatole < > > > [email protected]> wrote: > > > > > >> Can you explain (or post a link) that in more detail, people might not > > now > > >> much about Multiconf... > > >> > > >> -----Original Message----- > > >> From: Werner Keil [mailto:[email protected]] > > >> Sent: Mittwoch, 3. Dezember 2014 13:16 > > >> To: [email protected] > > >> Subject: Re: Use Case 1: Read simple properties and get values. > > >> > > >> I would go a bit beyond a simple "ConfigFormat" based on the > experience > > >> with Multiconf in a very large Cloud environment. > > >> What was used there aside from obvious (JSON) data exchange or output > > one > > >> might consider "format" is more towards "ConfigReport" or whatever you > > >> might call that. > > >> We used Asciidoc and with several Asciidoc and Asciidoctor affine > > members > > >> here I guess that could also work for Tamya;-) > > >> > > >> Werner > > >> > > >> On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole < > > >> [email protected]> wrote: > > >> > > >> > @Romain > > >> > > > >> > The concept is - as I said - that you can describe, from which > source > > a > > >> > configuration should be read. This descriptions goes first to a > > reader, > > >> > which knows how to resolve the location and resolves to a number of > > >> > URIs/input streams. > > >> > These input streams can come in multiple formats (even mixed). > > >> > Configuration Format and reader are the abstraction so you can write > > >> > basically something like > > >> > > > >> > PropertyProvider prov = PropertyProviders.fromPath(" > reader:whatever"); > > >> > > > >> > In the example above you can declaratively define a > PropertyProvider, > > >> fast > > >> > and easy, and you (by default) do not have to care on the format > (BTW > > it > > >> is > > >> > possible that multiple formats register for the same file ending). > > >> > Removing ConfigFormat means, that you > > >> > - only support a limited set of formats, or > > >> > - must implement format parsing logic yourself also for the most > > common > > >> > cases, and > > >> > - create additional implementation dependencies on the format > parsing > > >> code > > >> > - and probably you have to duplicate the logic that converts an > > >> > InputStream into a Map<String,String>/ProeprtyProvider. > > >> > > > >> > Finally: the project is internally split up into an API part and an > > >> > implementation part. ConfigFormat is not part of the API (you > > typically > > >> > will not code against it). If you have really want to write all your > > >> > providers yourself, you can do that. Nobody prevents you doing so, > but > > >> > please allow other maybe less sophisticated users to benefit from > > >> provided > > >> > features, so they do not have to write them themselves. > > >> > And once more, this feature was a great help for supporting > muiltiple > > >> > formats such as .properties, .xml (xml-properties), .ini > (ini-Files). > > I > > >> do > > >> > not see any reason we should remove something that has proven to > work > > so > > >> > nicely. > > >> > > > >> > Cheers, > > >> > Anatole > > >> > > > >> > > > >> > > > >> > -----Original Message----- > > >> > From: Romain Manni-Bucau [mailto:[email protected]] > > >> > Sent: Mittwoch, 3. Dezember 2014 12:18 > > >> > To: [email protected] > > >> > Subject: Re: Use Case 1: Read simple properties and get values. > > >> > > > >> > I don't fully agree. Where is passed through PropertyProviders so > > >> > basically we don't need this format abstraction. Providers should > just > > >> > check it can read it or not. having such an indirection already > makes > > >> > the framework "apparently" complex enough to not be used from my > point > > >> > of view. > > >> > > > >> > Implementing a custom provider to read what you want is generally > > >> > trivial enough to be where the extenisbility is. > > >> > > > >> > > > >> > Romain Manni-Bucau > > >> > @rmannibucau > > >> > http://www.tomitribe.com > > >> > http://rmannibucau.wordpress.com > > >> > https://github.com/rmannibucau > > >> > > > >> > > > >> > 2014-12-03 12:13 GMT+01:00 Anatole Tresch <[email protected]>: > > >> > > Far this is not the same. A provider defines where configuration > is > > >> read. > > >> > > The format defines how. Even properties files may lay at multiple > > >> > > locations, could be locally , classpath, blobs, remotedly, ... I > > want > > >> to > > >> > > support users that they are able to read configuration with > minimal > > >> > coding > > >> > > required. > > >> > > > > >> > > This model is flexible and is the reason we reading in uc1 is so > > simple > > >> > and > > >> > > will be similar easy also for enterprise specific custom formats. > > >> > Companies > > >> > > will never change their existing formats just to use Tamaya... > > >> > > Romain Manni-Bucau <[email protected]> schrieb am Mi., 3. > Dez. > > >> 2014 > > >> > um > > >> > > 11:45: > > >> > > > > >> > >> +1, ConfigFormat or PropertyProvider shouldn't be there. > > >> > >> > > >> > >> > > >> > >> Romain Manni-Bucau > > >> > >> @rmannibucau > > >> > >> http://www.tomitribe.com > > >> > >> http://rmannibucau.wordpress.com > > >> > >> https://github.com/rmannibucau > > >> > >> > > >> > >> > > >> > >> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer < > > [email protected] > > >> >: > > >> > >> > So if a new ConfigFormat is required for reading a different > data > > >> > source: > > >> > >> > What is the difference between ConfigFormat and > PropertyProvider? > > >> > Isn't > > >> > >> it > > >> > >> > the same? > > >> > >> > > > >> > >> > IMHO we have to discuss the overall architecture a least a > little > > >> bit > > >> > to > > >> > >> see > > >> > >> > which parts exist, how they interact and who is responsible for > > >> what. > > >> > >> > > > >> > >> > Oliver > > >> > >> > > > >> > >> > Am 03.12.14 01:15, schrieb Anatole Tresch: > > >> > >> >> > > >> > >> >> BTW, supporting a new ConfigFormat is trivial: implementing > > >> > >> >> ConfigurationFormat > > >> > >> >> and register it with as component, by default using the > > >> > ServiceLoader. > > >> > >> >> Then you only to read the file and you are done ;) > > >> > >> >> > > >> > >> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek < > > >> > [email protected] > > >> > >> >: > > >> > >> >> > > >> > >> >> > > >> > >> > > > >> > >> > -- > > >> > >> > N Oliver B. Fischer > > >> > >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > > >> > >> > P +49 30 44793251 > > >> > >> > M +49 178 7903538 > > >> > >> > E [email protected] > > >> > >> > S oliver.b.fischer > > >> > >> > J [email protected] > > >> > >> > X http://xing.to/obf > > >> > >> > > > >> > >> > > >> > > > >> > > >
