polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: Configuration initialization
Date Mon, 13 Jul 2015 10:58:23 GMT
Niclas Hedhman a écrit :
> We all should know that Configuration Composite is an Entity, read from an
> EntityStore and runtime modifiable just like any Entity.
> We also know that if it is not found in the Entity Store, the value is read
> from a properties file, named after the identity of the Service Composite
> the configuration belongs to.
> I am now adding that in addition to Properties files, the file can be read
> via ValueSerialization instead. I am also adding that YAML is a format we
> intend to support (I really like that format for Config data).
> But currently there is no YAML ValueSerialization extension available. If
> someone feels itchy to help out; Creating a ValueSerialization extension
> for YAML, with the help of SnakeYaml or YamlBeans.
> Since the code is virtually the same inside the Configuration, I will rely
> on this will get done sooner or later, and my tests are only covering JSON
> and XML for now.

I took a couple hours to start a YAML serialization extension. Both
SnakeYaml and YamlBeans gave me headhaches when it came to switching
from pull-parsing to tree-parsing for deserialization. Looks like theses
libraries are not built for advanced usecases. I'll need some more time
to come up with something usable.

Niclas Hedhman a écrit :
> And to make this more "integrated", I am introducing
> ModuleAssembly.configurations()
> since otherwise people will be confused that both a entity and a value
> needs to be declared.
> (Actually, this speaks even more in favor of proposal to
> "Entity=Identity+Value")
> The assembly will take care of duplicating the declared types as both
> entities and values, so there won't be a ConfigurationInstance type, at
> least not in 2.1.
> Any thoughts?

I'm all in favor for going towards "Entity=Identity+Value". In the end,
this will allow us to drop a bunch of code as EntityState serialization
in EntityStores is pretty different than ValueSerialization (was already
before I rewrote ValueSerialization for 2.0). And I don't see the need
for theses differences.


View raw message