On Tue, 14 Dec 2004 20:42:04 -0500 Peter Hyman <[EMAIL PROTECTED]> babbled:
(B
(B> On Tue, 2004-12-14 at 19:53 -0500, Michael Jennings wrote:
(B> 
(B> > Your preference doesn't enter into it, to be blunt.  The use of DB
(B> > files was discussed and decided on a long time ago.  You're not saying
(B> > anything here that hasn't been said before...just reopening old
(B> > gripes.
(B> 
(B> Well, excuse me. Don't be elitist.
(B> > 
(B> > > IMHO, there is no advantage to having that ONE file as an edb
(B> > > one. No other part of entrance uses it.
(B> > 
(B> > So you're advocating turning this one particular file into text and
(B> > leaving the rest as DB files?  That doesn't sound very *consistent*,
(B> > now does it?  :-)
(B> 
(B> No. There is one db file that Entrance uses. The rest are EET. This
(B> config file is in etc where all but one file I can think of are text. I
(B> fail to see how my "gripe" as you call it is unreasonable. I also fail
(B> to see how making a config file open, without having to write a program
(B> to edit it is unreasonable,
(B
(Band we are moving to eet. the core of this is text vs binary config. the fact is
(Ba binary config makes for a much stricter format and thus puts less burdens on
(Bthe parser. they are not intended to be just "edited". we are providing and will
(Bprovide more tools to DO those edits FOR you in an organised and clean fashion.
(Bwe are sticking to binary as its compact, efficient, can store a lot more
(Binformation much more efficiently and cleanly than a text config. this is why we
(Bchoose consistency. this file entrance uses is a bit old. ecore_config is the
(Bway to go. it does have issues atm in terms of abilities - e17 itself is
(Bdiverging a bit for now and using its own config .eet's (it actually uses .cfg
(Bextensions but they are .eet files). the fact is we provide a clean API to
(Baccess the file. we have tools to access that (mind u - with issues) and this is
(Binherently cleaner than forcing people to use a text editor as it does not
(Brequire them to learn any syntax or magic and provides much less scope for them
(Bto "screw things up".
(B
(B> I suppose, it depends on who you think your audience is. If it's people
(B> like me, end users that enjoy the latest in tech trends and like to
(B> tinker, then your library-only approach to configuration editing is not
(B> going to fly. If it's a narrow group of programmers and graphics
(B> wizards, then I suppose it will be fine.
(B
(Bwe don't advocate forcing uses to write their own programs just to edit/change a
(Bconfig - that is why we have tools to do that for you, or are working on them.
(B:)
(B
(B> However, just because someone thinks there is a more practical way to do
(B> something is no reason to flame. If I am too "ignorant" for your tastes
(B> then perhaps I am wasting my time trying to figure out what E is all
(B> about.
(B
(Bno - i agree - your opinion is valid, and you have valid points, but we went
(Bover this a long time ago (as kainx said) and weighed up the 2 sides of the
(Bargument and decided binary comes out on top and so are sticking to our guns. (i
(Bwill flagilate myself right now for e17's .order files. they are text. mind you
(Bthey are filename<newline>filename<newline> - i am struggling to see how binary
(Bimproves this... well i guess if u want filenames WITH newlines in them you are
(Bscrewed... for now i shall discount that as an insane few people who should be
(Bflagilated more than me) 
(B
(Banyway - the point of a binary config is:
(B
(B1. stop people just poking around and screwing things up and thus having to do
(Bsanity checks galore on load/parse
(B2. simpler smaller parsing code
(B3. more compact files
(B4. able to EASILY and EFFICIENTLY inline data that isn't just config "values"
(Blike inline the "icon" or image data for something.
(B5.  being able to collate multiple configs and pieces of data into 1 file so
(Bbreaking things by removing "half" the configuration (by moving or deleting
(Bneeded files) is less likely.
(B6. embedded efficiency - yes guess what. embedded devices have 100 or 200 or
(B400mhz cpu's and parsing text is much more work than parsing binary :)
(B7. this FORCES us to stop being lazy and just go and say "go edit the config
(Bfiles". it is self discipline "helpers" and forces us to write better tools
(Binstead of using the "sledgehammer to fix all problems" that a text editor is.
(Bhopefully it encourages us to even add easy to use gui's on  these tools too.
(B8. it helps encourage us to attach ipc ports to programs so instead of just
(Bsaying "go edit the config file and restart" which is what nigh every unix
(Bprogram on the planet has done since the dawn of time, we make a programs setup
(Bdynamic, being able to connect to the program and go "btw - go do this now,
(Bchange this to this etc." and thus not require restarts and edits of configs.
(Becore_config actually does a chunk of this already "for the app".
(B
(Byour point that "maybe THAT file could be text" is valid, but we prefer to aim
(Bfor consistency for all our work in the future and "exceptions" just make it
(Bmore painful as sooner or later you need to run into the binary monster (themes
(B- i challenge you do do edje's theme files more efficiently/effectively using
(Btext files only), so we may aswell introduce the "binary monster" from day one
(B:)
(B
(Bso yes - you have valid points. most of the issues are teething problems you
(Bwill find in software AS IT IS DEVELOPED. we haven't gone and put up tarballs of
(Bentrance have we? have we released entrance 1.0 and gone to encourage
(Bdistributions to use it? right now its a work in progress. getting better. our
(Breal aim is hopefully to have it all solid and done in time for e17's wm release
(Balong with everything else and do one huge release of everything at once, all
(Bwell tested, quality assured and solid. the "release early, release often" for
(Buse == CVS and that is the "expect bugs and errors if u deal with CVS" :)
(B
(Bbut we value feedback and points of view. we realise there are many. long ago we
(Bhoped to even make the configuration of e configurable. make all people able to
(Bchoose the method best for them. i learnt the hard way that that just doesn't
(Bwork. people will use the default method given and never try expand/change it.
(Bso we moved to doing it for them and "going all the way".
(B
(B:)
(B
(B> -- 
(B> Peter
(B> 
(B> 
(B> 
(B> -------------------------------------------------------
(B> SF email is sponsored by - The IT Product Guide
(B> Read honest & candid reviews on hundreds of IT Products from real users.
(B> Discover which products truly live up to the hype. Start reading now. 
(B> http://productguide.itmanagersjournal.com/
(B> _______________________________________________
(B> enlightenment-devel mailing list
(B> [EMAIL PROTECTED]
(B> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
(B> 
(B
(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

Reply via email to