This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mon, 2003-03-10 at 07:08, Michael A Chase wrote: > On Sun, 9 Mar 2003 16:38:57 -0000 Max Bowsher <maxb at ukf dot net> wrote: > > > Igor Pechtchanski wrote: > > > There have been bits of persistent state that people wanted to store > > > for setup. I'm proposing an Xdefaults-style setup.cfg in /etc/setup. > > > If we compile a list of things to go in there, I could write a parser > > > for it (I don't think it merits yacc, like the one for setup.ini :-D) weeel :}. If not yacc, then I'm going to want something clean and extensible. (i.e. you may prefer yacc as a lower hurdle :}). Not that I love yacc BTW. Perhaps the Interpreter pattern is appropriate, or the (is there a pattern) common persistence idiom where each object serialises itself. Key code requirements: * Settings must not be centralised in the code. * GUI must not be a requirement (text mode setup tools already exist). * Must be robust to handle text/bin issues and users fiddling - OR 100% opaque to the user. (i.e. if it looks like users can fiddle, we must survive them fiddling). > > Ok, but we need to decide: Is this going to be user-edited, or > > setup-edited? > > I.e., there is no point in allowing comments, if they get removed every > > time setup re-writes the file. > > There is probably no harm in allowing comments, just have the first > one written by setup warn that the file is generated by setup so manual > changes will be overwritten. If we have a comment object in the language, it will get inserted in the outbound file. It's trivial to do that with even a simplistic design. I don't have a particular opinion on comments myself. > As for what to do before the mount points are created, what happens > to the mirror list now if all the user does is download files and > Cygwin isn't installed locally? Use the source Luke. Now, I have a couple of comments that should be made... I'm very much pro-this. I've made enough comments about 'when I get around to... common config' in the archives. We have two forms of persistent data: * User driven data (chosen mirrors for example) * 'System' driven data (what files are in package foo, what official mirrors exist, timestamps ...) The requirements I've laid out above apply *only* to the User driven data. I'll be placing a sanity test regarding that on any patch :}. System data has somewhat different needs, and we can look at refactoring the user data framework when we come to tackle system data. Also, I'd prefer /etc/setup.rc rather that /etc/setup/setup.cfg. Finally, I suggest that rather than coding in all the *new* settings one would like to store, that the existing ones get refactored - and the migration strategy implemented and tested - and we get that into HEAD. An options setting framework that handles the existing persistent UI choices will handle most anything we want to throw at it. -- GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |