Il giorno ven, 09/03/2007 alle 13.30 -0700, Tom Tromey ha scritto: > >>>>> "Mario" == Mario Torre <neugens@xxxxxxxxxxxxxxxx> writes: > ated service files. > > That said, I think we should probably not use this approach to > configure Classpath itself, at least not for areas where the user > might need to be able to override the default. In those situations, > maybe compiling in a default system property would be better. Yeah, I agree about that. FWIW, the preferences look at a system property first, that go to look the default in the service and then revert to the hardcoded class. For classes that can be configured at runtime, like the desktop api, I have just created two options, a system property (for each action/method) and a preference (same as the system property). The system property has precedence always, so a user can ovverride the default from the command line. The preference has precedence only over the default (that in that case depends on the detected desktop, for other things can be hardcoded). This has the nice side effect that packagers/users can override the settings at runtime. This approach can be a security risk in some cases, so we should pay attention for any given case. The problem I see here, though, is an "organisation" problem (I like the english sound, with the 's'. The american one is similar to the italian :) : keep track of all the preferences (and then on the system properties) instead to have them just forgotten in the .java files. About that, I'm working on a tool that let, at least for now, to configure the preferences described in a config file (xml). This file can be generated by the build system or just be there for use. For now just the preferences are supported (and only for the Desktop API, because it uses the Preferences API), so that could need some code changes. Runtime behaviour by mean of system properties is my goal, though. If this is a reasonable approach, I would suggest to follow that when writing new classes. All the options should be documented in some README.options or README.configurations file too (I've started this too, but I'm running out of time!). What do you think? > Tom Ciao! Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens@xxxxxxxxxx - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente
