XML/XSD based configuration files.
Frans Englich
frans.englich at telia.com
Tue Dec 7 22:55:38 GMT 2004
On Tuesday 07 December 2004 19:14, Cristian Tibirna wrote:
> On Tuesday 07 December 2004 13:44, Frans Englich wrote:
> > > needed. XML is not nearly as human friendly, and i think that's an
> > > important thing to keep in mind as well.
> >
> > I would consider that such a low priority it can be neglectable; that
> > people need to manually hack files is the bug, not that it's difficult.
>
> I'm sure that if you read the above you disagree with yourself. Needing to
> manually manipulate own data (configurations in this case) isn't a bug.
> It's an inalienable right!
If you like. A right a small percentage of our users has the skills and
interest to exercise. It's nothing wrong with having that right, it just
doesn't matter for the vast majority of our users -- the /overall/ result
wouldn't be nice if we went for a solution which made it top notch for geeks
like us, and made it negative for the wide majority. This is getting
theoretical(not that it isn't needed).
> And that's one of the reasons Windows obscures
> config in the first place, very probably.
(Similar to how integration does not equal lock-in -- Konqueror has
integration without lock-in -- does the inability to manually edit physical
text files not mean that user influence cannot be reached in other ways.)
However, I think Aaron's comments on the matter shows flaws in my reasoning --
the ability is not fully neglectable as I wrote; it do matters for the IRC
case, for example. One can draw a parallel to XML; one reason it took off,
from what I have read, was its low entry threshold; it didn't require some
obscure tool for inspecting a binary format, only a plain text editor.
The ability to manually edit text files(if that's now the physical format)
isn't irrelevant as I initially wrote, but it sure must have a low
priority(and where how much it is compromised depends on how important other
aspects of the matter are).
Cheers,
Frans
More information about the kde-core-devel
mailing list