1) Versioning
Make sure your top level element contains all the version information that
you need. When you switch versions, change this number and also add version
information to any nodes that change substantially enough to require.
Basically what I am getting at is that the version
On Mon, 30 Sep 2002, Chris Nuernberger wrote:
What the hell does this mean? Obviously it is a modeline for 1024x480 but
the rest of it is cryptic.
ModeLine 1024x48065.00 1024 1032 1176 1344 480 488 494
563 -hsync -vsync
FYI, there is a tutorial on Configuring XFree86 at
Apropos this XML config stuff...
I once thought of creating a rambased filesystem like devfs, but for XML
configuration files.
You would then mount the filesystem in let's say /xetc and when first
mounted a daemon (like devfsd) transforms all (or those who have been
choosen) configuration
Exactly this would make conversion to and XML file
format seemless and easy once the programs were
converted then the XML file system would continue to
be of use but in this case simple as a front end for a
data base.. The XML file system represents and easy
way to access XML data without
As an intermediate solution, can you write a tool
that would generate
XML from a normal config file, and then convert the
XML back into the
config file? You'd probably have to do something
specialy to handle
comments so that users don't lose their comments in
the process.
I
--- Keith Packard [EMAIL PROTECTED] wrote:
My hope is that the configuration file becomes
entirely optional. There's
essentially nothing there which can't be
autodetected on a reasonable
system.
At that point, the format of the file is moot.
Actually long term I was hoping for
Around 14 o'clock on Oct 3, Michael Michael wrote:
The big picture is I'd like to move towards a XML format for flat file view
and database for ui managers. Moving to XML helps a lot in moving on to a
system wide config data base. A zillion config file formats makes it
difficult to
On Thursday 03 October 2002 5:33 pm, Michael Michael wrote:
--- Keith Packard [EMAIL PROTECTED] wrote:
My hope is that the configuration file becomes
entirely optional. There's
essentially nothing there which can't be
autodetected on a reasonable
system.
At that point, the format
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 1 Oct 2002 14:31, Keith Packard wrote:
My hope is that the configuration file becomes entirely optional. There's
essentially nothing there which can't be autodetected on a reasonable
system.
And hopefully auto(re)configured, based on
On Tue, 1 Oct 2002 02:01 pm, Keith Packard wrote:
My hope is that the configuration file becomes entirely optional. There's
essentially nothing there which can't be autodetected on a reasonable
system.
At that point, the format of the file is moot.
It has to be editable for those who still
this is in essence what you can see on the linux kernel mailing
list (and many others):
gee, i have a great idea for this new solution to your
existing module XYZ. i want to replace it with ABC. if
i do, will you take it?
the answer is that 'carte blanche' does not exist. the proof
On Tue, Oct 01, 2002 at 05:10:26PM +0930, Adam Luchjenbroers wrote:
On Tue, 1 Oct 2002 02:01 pm, Keith Packard wrote:
My hope is that the configuration file becomes entirely optional. There's
essentially nothing there which can't be autodetected on a reasonable
system.
At that point,
It has to be editable for those who still use a config file (custom settings,
modelines, etc) and personally I think the current format is quite nice for
hand-editing. What I've seen of XML doesn't have that quality.
For better, or for worse, XML looks like HTML, and many/most system managers
On Sun, 29 Sep 2002, Michael Michael wrote:
Has there been any discussion on translation of the
current XF86 config file to XML format.
Lots.
Some of us are very resistant to changing what we have at the moment.
See
http://www.xfree86.org/pipermail/xpert/2000-November/002982.html
for an
Has there been any discussion on translation of
the current XF86 config file to XML format.
Lots.
Some of us are very resistant to changing what we
have at the moment.
See
Couldn't someone invent an XML version of the format
and write a little translator program (or script) so
that
--- Dr Andrew C Aitchison
[EMAIL PROTECTED] wrote:
On Sun, 29 Sep 2002, Michael Michael wrote:
Has there been any discussion on translation of
the
current XF86 config file to XML format.
Lots.
Some of us are very resistant to changing what we
have at the moment.
It seem that XF86
On Mon, 30 Sep 2002, Michael Michael wrote:
after 1990... Note these arguments are the standard
anti-xml arguments given by most idots..
Okay, I will assume that you are not a troll just so I can put forth some
of the non-standard arguments:
1) Versioning
XML *still* doesn't have any good
MM Note these arguments are the standard anti-xml arguments given by
MM most idots..
The XML proposals I've seen have been of the form ``I've just met
Goedel in the lift, and he told me XML is a good idea, so why don't
you folks implement XML for the server configuration file.'' Yours is
the
--- Andrew P. Lentvorski [EMAIL PROTECTED]
wrote:
On Mon, 30 Sep 2002, Michael Michael wrote:
after 1990... Note these arguments are the
standard
anti-xml arguments given by most idots..
Okay, I will assume that you are not a troll just so
I can put forth some
of the non-standard
On Mon, Sep 30, 2002 at 02:58:02PM -0700, Michael Michael wrote:
Like i said its usefulness is proven in many areas.
I see no reason not to use it. It could be introduced
without effecting the current parser.
Current parser aside, how do you deal with the people who want to:
root# vi
My hope is that the configuration file becomes entirely optional. There's
essentially nothing there which can't be autodetected on a reasonable
system.
At that point, the format of the file is moot.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
Has there been any discussion on translation of the
current XF86 config file to XML format. This would
make it extremely easy to develop UI base
configuration systems for XFree and also offer and
easy way to validate the config file. The current
parser could be easily modified to generate and
22 matches
Mail list logo
