It is certainly reasonable to want to see a proposal for an
XML DTD for an XFree86 config file.

The view of reality I see is that, for better or worse, XML is something 
familiar to an increasingly large fraction of the user base (particularly 
the hacker types who might edit such a file by hand), and the current 
XFree86 config file syntax is not (nor is it friendly for building tools 
to generate them). So if we take as a given wanting a config file syntax 
that is both human and machine read/writeable easily, one can do alot worse
than XML (like where we are right now).

I've personally been burned by the config file's syntax in the last month 
or two, as I reinstalled several of my systems, one of which ended up 
broken after insall. And I've been burned by the quoting problem
used as the other example on several occasions.

So my opinion goes as follows:

        1) We need to make the need for the XFree86 config file as small as 
possible.  We need to work hard at getting defaults right, so they don't 
have to be edited in the first place, nor things specified, unless you
are doing something particularly unusual. 

I give as a concrete first hand example: On my Matrox G450, 
        o the default depth is 8! So for it to be even semi-sane, 
        you have to go touch what is generated. 
        o Furthermore, to get TT fonts, you have to go edit the file 
        to add a module.  I still don't understand why there are two
        choices here for modules, other than some handwaving Keith gave
        me about eastern fonts (we could make the default locale dependent
        if necessary). 
        o And the mouse does not default to the most common 
        forms of mice currently found, (nor autodetect the protocol) etc....  
        o And the server defaulted to trying to use the absolutely highest 
        supported resolution of my monitor (2100x1600), which, until we use 
        scalable fonts  everywhere, is probably the wrong answer, much less 
        the fact the second DAC on the G450 can't go that fast, and will therefore
        be wrong for xinerama.
There are therefore at least *four* things a poor user has to do to get 
it going, even ignoring xinerama (which I've put off reenabling, preferring 
to get work done to messing further with my config file any futher).

We can/should do *alot* better, folks. We're being sloppy, hiding behind 
the fact the distribution vendors often clean up after us.  

The problem with the view that the distro vendors fix it, is that if you
fall off the beaten path, you are currently in XF86Config file hell...
And then we end up with tons of support questions soaking our time,
along with alot of disgruntled people who say: "this open source software
stuff is for the birds".

        Ideally, on sane hardware (which the industry is slowly moving
toward), the file can/should be empty, and the server work decently....

I *really* don't want to get a merit badge for editing my configuration
file manually: I deserve one right now, unfortunately.

        2) we need to bite the bullet and adopt a config file format
that is both amenable to hand editing (which we should minimize by 1),
and by tools (which is what most end users want and need).  The
current format is not: or we'd have to build tools to write the format,
and such tools would have different API's than already being used for
other system configuration metadata, which seems to be most often using XML
these days.

I don't see the current situation as something we can/should live
with for any longer than absolutely necessary.

Don't take this as a statement of love for XML; I'd have preferred a 
s-expression syntax, but due to the history of HTML coming from SGML, 
we end up with <> as the dominant way of storing such data. Sigh.... But 
it can be machine read and written, validated to a significant degree, 
and hand edited when necessary (and then validated).  This seems like
a win to me.

                                - Jim


--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
[EMAIL PROTECTED]

_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to