On Fri, 20 Oct 2017 11:15:09 -0200 Gustavo Sverzut Barbieri <[email protected]> said:
> On Thu, Oct 19, 2017 at 9:15 PM, Carsten Haitzler <[email protected]> > wrote: > > On Thu, 19 Oct 2017 14:28:27 -0200 Gustavo Sverzut Barbieri > > <[email protected]> said: > > > >> > + get { > >> > + keys { > >> > + name: string; [[Configuration option name.]] > >> > >> shall we document and handle this as a path, so nested Eets can be > >> used, such as in E (wm). > > > > I'm not so sure this config API is "good enough". It is indeed very very > > simple (string key to single value pair). But history tells me that this is > > very limiting. I've been here before (edb) and i hit the limits of this > > pretty fast. I needed SETS of things (a list of strings. a list of > > keybindings, a list of whatever) very quickly. I think that this should be > > an API which allows nesting and "sets" (ordered lists/array of items with > > the ability to append, prepend, insert and remove) and probably also > > "hashmaps" as well (key -> item lookup). yes. it's more complex, but at > > least it won't hit a wall really really fast and then we need to extend > > this api so it begins to look a bit ugly after extending. > > all possible with Eina_Value, you can return a list, array, hash or struct. > > So let's say: key "a/b/c[0]" is a struct member "a", there hash key > "b", there a struct member "c" that is an array, where you want the > first index, which is a string. oh. i didn't remember there being a struct type... just the basic ones. ok. well that does solve things indeed. > a/b/c[0]: returns string > a/b/c: returns an Array of String > a/b: returns a struct > a: returns a hash > (empty): returns a struct > > all of these can be done with Eina_Value as return. > > > > also i'm not sure if it should also allow for fallbacks (look for val in > > config store X - if not there, look in Y, if not there look in Z. this is > > common for looking in user config first then falling back to system > > config ... but we don't do it value by value atm... but needing to be able > > to defined where those config stores are would be important big-picture, > > with probably a default of system + user). > > not sure for desktops, but for servers and the more-and-more common > "stateless setups", where /usr is RO and you don't want to force /etc > or /var writes until explicitly needed (ie: not forcing > /etc/myserver.cfg unless something was written, and there only keep > what really changed). sure. this is why i think the api needs a way to "switch" the fallback handling policies, or explicitly list fallback locations etc. > Intel's ClearLinux is like that, all default configuration files are > stored under /usr (not /etc) or built-in the binaries (default > variable assignments) and /etc is only used to override some pieces... > Systemd, udev and kmod all make this simpler > > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
