Hi all,
(B
(B I think this reply from raster should be put up
(B on edevelop.org somewhere. Because I have seen
(B this discussion happening a lot of times on the
(B list. I have to give it to raster for being so
(B patient and replying to everybody who starts a
(B discussion on this subject.
(B
(B However, raster's time is best employed in writing
(B the e17-wm :).
(B
(B What say?
(B
(B-vikas
(B
(BCarsten Haitzler (The Rasterman) wrote:
(B> On Tue, 14 Dec 2004 20:42:04 -0500 Peter Hyman <[EMAIL PROTECTED]> babbled:
(B>
(B>
(B>>On Tue, 2004-12-14 at 19:53 -0500, Michael Jennings wrote:
(B>>
(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>
(B>
(B> and we are moving to eet. the core of this is text vs binary config. the fact
(B> is
(B> a binary config makes for a much stricter format and thus puts less burdens on
(B> the parser. they are not intended to be just "edited". we are providing and
(B> will
(B> provide more tools to DO those edits FOR you in an organised and clean
(B> fashion.
(B> we are sticking to binary as its compact, efficient, can store a lot more
(B> information much more efficiently and cleanly than a text config. this is why
(B> we
(B> choose consistency. this file entrance uses is a bit old. ecore_config is the
(B> way to go. it does have issues atm in terms of abilities - e17 itself is
(B> diverging a bit for now and using its own config .eet's (it actually uses .cfg
(B> extensions but they are .eet files). the fact is we provide a clean API to
(B> access the file. we have tools to access that (mind u - with issues) and this
(B> is
(B> inherently cleaner than forcing people to use a text editor as it does not
(B> require them to learn any syntax or magic and provides much less scope for
(B> them
(B> to "screw things up".
(B>
(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>
(B>
(B> we don't advocate forcing uses to write their own programs just to
(B> edit/change a
(B> config - that is why we have tools to do that for you, or are working on them.
(B> :)
(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>
(B>
(B> no - i agree - your opinion is valid, and you have valid points, but we went
(B> over this a long time ago (as kainx said) and weighed up the 2 sides of the
(B> argument and decided binary comes out on top and so are sticking to our guns.
(B> (i
(B> will flagilate myself right now for e17's .order files. they are text. mind
(B> you
(B> they are filename<newline>filename<newline> - i am struggling to see how
(B> binary
(B> improves this... well i guess if u want filenames WITH newlines in them you
(B> are
(B> screwed... for now i shall discount that as an insane few people who should be
(B> flagilated more than me)
(B>
(B> anyway - the point of a binary config is:
(B>
(B> 1. stop people just poking around and screwing things up and thus having to do
(B> sanity checks galore on load/parse
(B> 2. simpler smaller parsing code
(B> 3. more compact files
(B> 4. able to EASILY and EFFICIENTLY inline data that isn't just config "values"
(B> like inline the "icon" or image data for something.
(B> 5. being able to collate multiple configs and pieces of data into 1 file so
(B> breaking things by removing "half" the configuration (by moving or deleting
(B> needed files) is less likely.
(B> 6. embedded efficiency - yes guess what. embedded devices have 100 or 200 or
(B> 400mhz cpu's and parsing text is much more work than parsing binary :)
(B> 7. this FORCES us to stop being lazy and just go and say "go edit the config
(B> files". it is self discipline "helpers" and forces us to write better tools
(B> instead of using the "sledgehammer to fix all problems" that a text editor is.
(B> hopefully it encourages us to even add easy to use gui's on these tools too.
(B> 8. it helps encourage us to attach ipc ports to programs so instead of just
(B> saying "go edit the config file and restart" which is what nigh every unix
(B> program on the planet has done since the dawn of time, we make a programs
(B> setup
(B> dynamic, being able to connect to the program and go "btw - go do this now,
(B> change this to this etc." and thus not require restarts and edits of configs.
(B> ecore_config actually does a chunk of this already "for the app".
(B>
(B> your point that "maybe THAT file could be text" is valid, but we prefer to aim
(B> for consistency for all our work in the future and "exceptions" just make it
(B> more painful as sooner or later you need to run into the binary monster
(B> (themes
(B> - i challenge you do do edje's theme files more efficiently/effectively using
(B> text files only), so we may aswell introduce the "binary monster" from day one
(B> :)
(B>
(B> so yes - you have valid points. most of the issues are teething problems you
(B> will find in software AS IT IS DEVELOPED. we haven't gone and put up tarballs
(B> of
(B> entrance have we? have we released entrance 1.0 and gone to encourage
(B> distributions to use it? right now its a work in progress. getting better. our
(B> real aim is hopefully to have it all solid and done in time for e17's wm
(B> release
(B> along with everything else and do one huge release of everything at once, all
(B> well tested, quality assured and solid. the "release early, release often" for
(B> use == CVS and that is the "expect bugs and errors if u deal with CVS" :)
(B>
(B> but we value feedback and points of view. we realise there are many. long ago
(B> we
(B> hoped to even make the configuration of e configurable. make all people able
(B> to
(B> choose the method best for them. i learnt the hard way that that just doesn't
(B> work. people will use the default method given and never try expand/change it.
(B> so we moved to doing it for them and "going all the way".
(B>
(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
(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
