On Tue, 30 Nov 2004 11:37:44 +0100 till varoquaux <[EMAIL PROTECTED]>
(Bbabbled:
(B
(B> They sure have thanks very much.
(B> Given the state of things (still under heavy devellopement) I guess I
(B> don't have much feedback to give concerning usability excepted:
(B> Why are all configuration files binary files?
(B
(B1. we hate writing parsing code.
(B2. binary files are significantly more efficient (in terms of space on disk,
(Baccess times, read times etc.) than text.
(B3. it allows use to save/encode ANY data - including images all to the same file
(B- not having to have a text config then image files separately scattered about
(Band loosely referenced.
(B
(B> A couple of days ago I set Entrance to use a theme that it didn't
(B> support... It kept on respawning so my computer was unusable (maybe we
(B> should say that after a couple of very respawns it stays put for a while
(B> but I think init should have done that). Anyways when I booted on a
(B
(Bwell actually entrance should just be fixed to detect respawn cycles and back
(Boff. this isn't a fault of binary config files.
(B
(B> rescue cd I was shocked to find the configuration file was binary
(B> (edb).A user not knowing how to use chroot cannot rescue his computer
(B> easily in such a case.
(B
(Byes - but the solution is the above, not changing config file format.
(B
(B> I guess those files are binary to keep things lighter (and they sure are
(B> impressively light) but would it really be much more expensive if they
(B> where in plain text (for instance in xml)?
(B
(Bthat depends. we use binary for the above reasons. entrance is actually uses a
(B.db file for config. everything else is using eet now - via ecore_config. we
(Bprovide a clean abstracted config mechanism api.
(B
(B> If so I have a suggestion:
(B> _Configuration files are saved in text mod. _When a programm boots up it
(B> builds the edb file and puts it somewhere else than /etc (say /var/cache
(B> for instance).
(B
(Booh yay! 2 configuration files and not knowing which one is actually being used.
(Bno. not doing this :) entrance needs some fixing here - but text config is the
(Bincorrect solution.
(B
(B> _On the next boot of this program it finds the edb file in /var/cache.
(B> This file is newer than the file in /etc therefore we don't need to
(B> parse the file in /etc
(B
(Bnow we need to create text -> db parsing and conversion code too.
(B
(B> To get thigs more secure (in case the system clock is changed or
(B> whatever) the mtime of the text configuration file could be saved in the
(B> edb file (which would be updated in case they didn't correspond).For
(B> systems not keeping time of mtime (I don't know if those exist) one
(B> could use a hash (for instance md5).
(B>
(B> Maybe my suggestions are planned features in which case please do excuse me.
(B
(Bthe real solution is just make the CODE better to 1. handle themes more robustly
(B(we need to go over this with entrance anyway) and 2. handle x config errors or
(Bothers with a respawn backoff.
(B
(Bbasically the reason for binary configs is 1. insanely efficient - we like to
(Bkeep efficiency in the core of e from the start of design. binary allows us to
(Bstore not just config values (strings, integers, etc.) but imagery, audio,
(Bmovies etc. any data at all that might be needed. it requires no special
(Bescaping and processing. just look up the file "key" index (a hash of the key,
(Blseek to index table at the start, jump to hash bucket, do minimal search for
(Bkey, then jump to given offset and blindly decode the data). this means we can
(Baccess any part of a config at random - when needed, not have to load it all
(Bfirst. the files are compact and have a defined format. we are all about
(Befficiency :) this gives us more cpu/resources to play with for that we really
(Bwant to do... fancy shit :)
(B
(Bin the end its just a matter of making the code a little more robust. - for
(Bexample detecting a corrupt config file and falling back to a known good system
(Bdefault. probably even making backups too as you go for revisioning, so if the
(Bcurrent file in an unlikely event gets destroyed you can roll back to a last
(Bknown "good copy" automatically without users having to fiddle with cp/mv/rm/vi
(Betc. by hand. i guess you argue that "making it easy to save your arses when all
(Bshit hits the fan with vi is good" - ok - but we argue "what if you don't know
(Bhow to use vi?" lets try make it work better for THAT case and needing vi or not
(Bis then a moot point :)
(B
(B--
(B------------- Codito, ergo sum - "I code, therefore I am" --------------
(BThe Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
$BMg9%B?(B [EMAIL PROTECTED]
(BTokyo, Japan ($BEl5~(B $BF|K\(B)
(B
(B
(B-------------------------------------------------------
(BSF email is sponsored by - The IT Product Guide
(BRead honest & candid reviews on hundreds of IT Products from real users.
(BDiscover which products truly live up to the hype. Start reading now.
(Bhttp://productguide.itmanagersjournal.com/
(B_______________________________________________
(Benlightenment-devel mailing list
([EMAIL PROTECTED]
(Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
