By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,426 Members | 3,338 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,426 IT Pros & Developers. It's quick & easy.

Why XML config files?

P: n/a
Ok, I wanted to ask this separate from nospam's ridiculous thread in hopes
it could get some honest attention.

VB6 had a some simple and fast mechanisms for retrieving values from basic
text files, which in turn could be simply and easily maintained with
notepad.

I understand the benefits of XML, really, but in the case of configuration
files it seems it is almost always nothing more than unnecessary complexity,
both in accessing them and maintaining them.

What am I missing?
Nov 15 '05 #1
Share this Question
Share on Google+
22 Replies


P: n/a
Daniel,

Well, you kind of answered your own question. The benefits of XML
become apparent when you need them. Granted, when things work, you wonder
why you need the extra complexity, but when you find yourself in a bind and
you have to make changes, you will be glad you have XML, as the number of
tools available to manipulate it are plentiful.

Also, like everything else in XML, it allows for easy insertion into
other business processes (I use business here loosely).

If you want, all of the routines in VB are implemented as static methods
in the Microsoft.VisualBasic namespace which is distributed with the
Framework (the classes for the most part are in Microsoft.VisualBasic.dll).
You can set a reference to this and use the methods as you would in VB
normally.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:um**************@TK2MSFTNGP10.phx.gbl...
Ok, I wanted to ask this separate from nospam's ridiculous thread in hopes
it could get some honest attention.

VB6 had a some simple and fast mechanisms for retrieving values from basic
text files, which in turn could be simply and easily maintained with
notepad.

I understand the benefits of XML, really, but in the case of configuration
files it seems it is almost always nothing more than unnecessary complexity, both in accessing them and maintaining them.

What am I missing?

Nov 15 '05 #2

P: n/a
The benefit of XML config file is that you are not limited
to just key/value settings, but you can have different
types of configurations that are more complex. Of course
you can achieve the same thing with regular text file, but
why reinvent the wheel.

Tu-Thach
-----Original Message-----
Ok, I wanted to ask this separate from nospam's ridiculous thread in hopesit could get some honest attention.

VB6 had a some simple and fast mechanisms for retrieving values from basictext files, which in turn could be simply and easily maintained withnotepad.

I understand the benefits of XML, really, but in the case of configurationfiles it seems it is almost always nothing more than unnecessary complexity,both in accessing them and maintaining them.

What am I missing?
.

Nov 15 '05 #3

P: n/a

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:%2****************@tk2msftngp13.phx.gbl...
Daniel,

...Granted, when things work, you wonder
why you need the extra complexity, but when you find yourself in a bind and you have to make changes, you will be glad you have XML, as the number of
tools available to manipulate it are plentiful.
Uh.. you mean like Editor, Notepad, Wordpad, Word, etc. ad infinitum? Come
on, you've got to do better than that. Please, I'm not trying to be flaming
sarcastic, but you just gave the argument for never "inventing" XML config
files in the first place.

Also, like everything else in XML, it allows for easy insertion into
other business processes (I use business here loosely).

If you want, all of the routines in VB are implemented as static methods in the Microsoft.VisualBasic namespace which is distributed with the
Framework (the classes for the most part are in

Microsoft.VisualBasic.dll).

That seems a rather nasty solution for my C# app.
Nov 15 '05 #4

P: n/a
Which is the cart and which is the horse? That is, by your own statement
("you can achieve the same thing with regular text file") didn't XML
reinvent the wheel?

"Tu-Thach" <an*******@discussions.microsoft.com> wrote in message
news:10****************************@phx.gbl...
The benefit of XML config file is that you are not limited
to just key/value settings, but you can have different
types of configurations that are more complex. Of course
you can achieve the same thing with regular text file, but
why reinvent the wheel.

Tu-Thach

Nov 15 '05 #5

P: n/a
Let me clarify... I meant my statement only to apply to config files, not
XML in general. The benefit is obvious when we start talking about
something complex like a representation of a DataTable, but config files
are typically fairly simple.

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:uc**************@TK2MSFTNGP10.phx.gbl...
Which is the cart and which is the horse? That is, by your own statement
("you can achieve the same thing with regular text file") didn't XML
reinvent the wheel?

"Tu-Thach" <an*******@discussions.microsoft.com> wrote in message
news:10****************************@phx.gbl...
The benefit of XML config file is that you are not limited
to just key/value settings, but you can have different
types of configurations that are more complex. Of course
you can achieve the same thing with regular text file, but
why reinvent the wheel.

Tu-Thach


Nov 15 '05 #6

P: n/a
I beg to disagree. Configuration files can be quite complex. Use of XML
for config files whenever your data is: nested rather than flat. For
example:
<servers>
<server type="development">
<database>
<name="mydatabase">
<users>
<user>
<name>smith</name>
<role>manager</role>
</user>
<user>
<name>jones</name>
<role>clerk</role>
<users>
</database>
</server>
<server type="production">
<database>
<name="yourdatabase">
<users>
<user>
<name>black</name>
<role>manager</role>
</user>
<user>
<name>white</name>
<role>clerk</role>
<users>
</database>
</server>
</servers>

Representing this in a flat INI type file is very complex if not impossible.
when new element groups are added to the INI file access code may break.
Since one has the power of Xpath and the XML DOM as part of the API one can
access groups of nested information quite easily ( \servers[server
@type="development]\users).
Also a new element groups may be added to the XML config file without
breaking older access code.

give it a try.

dlr

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Let me clarify... I meant my statement only to apply to config files, not
XML in general. The benefit is obvious when we start talking about
something complex like a representation of a DataTable, but config files
are typically fairly simple.

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:uc**************@TK2MSFTNGP10.phx.gbl...
Which is the cart and which is the horse? That is, by your own statement ("you can achieve the same thing with regular text file") didn't XML
reinvent the wheel?

"Tu-Thach" <an*******@discussions.microsoft.com> wrote in message
news:10****************************@phx.gbl...
The benefit of XML config file is that you are not limited
to just key/value settings, but you can have different
types of configurations that are more complex. Of course
you can achieve the same thing with regular text file, but
why reinvent the wheel.

Tu-Thach



Nov 15 '05 #7

P: n/a
We don't disagree - I said quite clearly that config files are *typically*
fairly simple, but acknowledged XML is obviously better for more complex
situations.

Of course, we're talking theoretically here. I would be curious to see what
percentage of .NET apps have config files this complex vs. the kind that
could easily be handled by a flat text file.

I find your point about breaking flat text files interesting because for
simple configuration information I see a 6-line file with all kinds of XML
tags much more prone to maintenance problems than a simple 1 or 2 line flat
file.

I don't think we need to keep going 'round and 'round on this. I made this
comment because I saw a *few* valid points in another thread which claimed
something like OO principles and n-tiered applications were the work of
satan. Obvious nonsensical drivel. I do, however, personally know of some
OO purists that always tend to make simple projects 10 times more complex
than they need to be, which in the long run costs somebody money.

So my point here is I just that this is an example - I think (with no
empirical evidence, of course) there are more cases than not that making
config files XML added unnecessary complexity. Could .NET have supported
both (without the VB namespace hack)? Hmmm.
"Dennis Redfield" <de*************@acadia-ins.com> wrote in message
news:OQ****************@TK2MSFTNGP10.phx.gbl...
I beg to disagree. Configuration files can be quite complex.


<snip>
Nov 15 '05 #8

P: n/a
You are missing the point, of maintaining uniformity and standardization
across the whole world.
Keyur Shah
Verizon Communications
732-423-0745

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 15 '05 #9

P: n/a

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:uT**************@TK2MSFTNGP12.phx.gbl...
We don't disagree - I said quite clearly that config files are *typically*
fairly simple, but acknowledged XML is obviously better for more complex
situations.

Of course, we're talking theoretically here. I would be curious to see what percentage of .NET apps have config files this complex vs. the kind that
could easily be handled by a flat text file.

I find your point about breaking flat text files interesting because for
simple configuration information I see a 6-line file with all kinds of XML
tags much more prone to maintenance problems than a simple 1 or 2 line flat file.

I don't think we need to keep going 'round and 'round on this. I made this comment because I saw a *few* valid points in another thread which claimed
something like OO principles and n-tiered applications were the work of
satan. Obvious nonsensical drivel. I do, however, personally know of some OO purists that always tend to make simple projects 10 times more complex
than they need to be, which in the long run costs somebody money.

So my point here is I just that this is an example - I think (with no
empirical evidence, of course) there are more cases than not that making
config files XML added unnecessary complexity. Could .NET have supported
both (without the VB namespace hack)? Hmmm.

No. Remember, while configuration files are generally pretty simple, but
configuration can include things like assembly version redirections, etc,
which while not in every configuratoin, support HAS to be there, it may be
needed. Splitting across different formats just complicates things
needlessly. The choice to provide the slightly more complex solution with
vastly superior flexibility is a good choice, in my opinion. Flat files
simplicity is not enough to make up for their lack of flexibility.

It is, in theory, possible for an developer to write an INI or whatever for
his own settings. I'd call their design into question, I consider INI's and
the registry to be for legacy use only by this point.
"Dennis Redfield" <de*************@acadia-ins.com> wrote in message
news:OQ****************@TK2MSFTNGP10.phx.gbl...
I beg to disagree. Configuration files can be quite complex.


<snip>

Nov 15 '05 #10

P: n/a

Hi Daniel,

Thanks for posting in this group.
I have reviewed your posts. I think you already know the much benefit of
the XML, but as you think, most of the configuration files in .Net are
simple, so it worths no while to introduce such "complex" technical for
them.
I think the uniform xml format for config files is for uniformity and
standardization(just as keyur said). Just so, the .Net can provide the
uniform way for accessing and managing these files.
For the text file "simplicity" and xml file "complexěty", I think this
points to the content of the configuration file. This simplicity based on
you manipulating the configuration file manually. While you maintain the
config files through program in .Net or other applications, I think plaint
text file's "simplicity" becomes not so simple(because of non static and
uniform architecture). While xml's "complexity" become more easy(because of
rich tools and access models). We should be aware of the percentage of
accessing config files manually or programmatically.
Also, all the config files in the xml format(whether short or long) are
more scalable.

Hope this helps,

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
| From: "Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com>
| References: <um**************@TK2MSFTNGP10.phx.gbl>
<10****************************@phx.gbl>
<uc**************@TK2MSFTNGP10.phx.gbl>
<#Y**************@TK2MSFTNGP09.phx.gbl>
<OQ**************@TK2MSFTNGP10.phx.gbl>
| Subject: Re: Why XML config files?
| Date: Tue, 11 Nov 2003 14:03:07 -0500
| Lines: 33
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <uT**************@TK2MSFTNGP12.phx.gbl>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: 68-74-16-211.ded.ameritech.net 68.74.16.211
| Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGXA06.phx.gbl!TK2MSFT NGXA05.phx.gbl!TK2MSFTNGP0
8.phx.gbl!TK2MSFTNGP12.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:198459
| X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
|
| We don't disagree - I said quite clearly that config files are *typically*
| fairly simple, but acknowledged XML is obviously better for more complex
| situations.
|
| Of course, we're talking theoretically here. I would be curious to see
what
| percentage of .NET apps have config files this complex vs. the kind that
| could easily be handled by a flat text file.
|
| I find your point about breaking flat text files interesting because for
| simple configuration information I see a 6-line file with all kinds of XML
| tags much more prone to maintenance problems than a simple 1 or 2 line
flat
| file.
|
| I don't think we need to keep going 'round and 'round on this. I made
this
| comment because I saw a *few* valid points in another thread which claimed
| something like OO principles and n-tiered applications were the work of
| satan. Obvious nonsensical drivel. I do, however, personally know of
some
| OO purists that always tend to make simple projects 10 times more complex
| than they need to be, which in the long run costs somebody money.
|
| So my point here is I just that this is an example - I think (with no
| empirical evidence, of course) there are more cases than not that making
| config files XML added unnecessary complexity. Could .NET have supported
| both (without the VB namespace hack)? Hmmm.
|
|
| "Dennis Redfield" <de*************@acadia-ins.com> wrote in message
| news:OQ****************@TK2MSFTNGP10.phx.gbl...
| > I beg to disagree. Configuration files can be quite complex.
|
| <snip>
|
|
|

Nov 15 '05 #11

P: n/a
>Of course, we're talking theoretically here. I would be curious to see what
percentage of .NET apps have config files this complex vs. the kind that
could easily be handled by a flat text file.


Well, even if there are only a few that benefit from having XML handle
the complexities, I think it's worth it going that way. I investigated
quite thoroughly whether we should use keep on using our trusty .INI
files instead - we gave up on it in the end, since there are some
cases (not many, but some) where the two-level section/key + value
just aren't enough.

Also, with all the XML support built right into the .NET framework,
you'd be foolish not to use it, and instead go back to re-invent the
wheel one more time.

Yes, XML is more complex and more verbose - get over it, and start
embracing it.

Marc
================================================== ==============
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
Nov 15 '05 #12

P: n/a
I remember being on a nightmare project where we were using .INI files to
store language translations, and running into huge problems with (lack of)
proper Unicode support. Oh, and I remember everything breaking if the files
grew larger than 64KB ...

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:uT**************@TK2MSFTNGP12.phx.gbl...
We don't disagree - I said quite clearly that config files are *typically*
fairly simple, but acknowledged XML is obviously better for more complex
situations.

Of course, we're talking theoretically here. I would be curious to see what percentage of .NET apps have config files this complex vs. the kind that
could easily be handled by a flat text file.

I find your point about breaking flat text files interesting because for
simple configuration information I see a 6-line file with all kinds of XML
tags much more prone to maintenance problems than a simple 1 or 2 line flat file.

I don't think we need to keep going 'round and 'round on this. I made this comment because I saw a *few* valid points in another thread which claimed
something like OO principles and n-tiered applications were the work of
satan. Obvious nonsensical drivel. I do, however, personally know of some OO purists that always tend to make simple projects 10 times more complex
than they need to be, which in the long run costs somebody money.

So my point here is I just that this is an example - I think (with no
empirical evidence, of course) there are more cases than not that making
config files XML added unnecessary complexity. Could .NET have supported
both (without the VB namespace hack)? Hmmm.
"Dennis Redfield" <de*************@acadia-ins.com> wrote in message
news:OQ****************@TK2MSFTNGP10.phx.gbl...
I beg to disagree. Configuration files can be quite complex.


<snip>

Nov 15 '05 #13

P: n/a
You folks are arguing for the need for XML config files in some cases, which
I've already admitted several times. I guess I should have made the subject
"why no more flat config files" to better represent my question.

In regards to supporting both simple flat files and XML files, I don't buy
the argument that it makes things too complicated. It doesn't seem any more
complicated to me than having to be aware of the way search paths worked in
DOS 6.22 or the way a web application can have multiple config files
scattered across several folders creating a complex hierarchy of config
settings. The rules would be quite simple:
1) look in a flat text file named xxx
2) look in the config file named xxx
3) XML takes precedence on conflict

Just think of a case where your config files only has one setting and you're
on the phone with a user of your software and you're trying to get them to
turn on verbose logging in the config file to track down some obscure bug...
would you rather have to walk the typical end user through changing a file
with one line

Logging=0
to
Logging=3

or have to get them to make the right change in an XML file. I'd take the
former any day. This is an example where the complexity of XML will
undoubtedly cost people money.

In fact, now that I think of it, the beauty of supporting both would be you
could put a few basic things like that in the .ini file and the more complex
stuff in the XML file.

As for .ini and registry being legacy, I think that is kind of a
self-defeating argument. We've been told for 5 years the registry was
supposed to make config files obsolete, and here we trying to get away from
the registry as much as possible and go back to config files. Maybe I'm
just an ornery old fart, but I'm very skeptical of the latest greatest new
directions from MS being the final word.

The "reinventing the wheel" argument is interesting too in that regard,
since XML config files is I guess the 3rd version now. I agree it's a good
reinvention, but that argument isn't logical - as if leaving flat file
support in .NET would have been a 4th version. No, it was the 1st. Yes, it
would be unwise of me to write my own flat config file support at this
point, but that's quite a different thing from MS leaving it in .NET.

Yes, there are reasons why XML config files are a great thing, but that
ain't two of them.

Now, the international/unicode argument is an interesting one. I wonder how
big the impact of that is though, from the standpoint of number of projects
it effects. Since XML is in reality a simple text file, how does it solve
that problem?

Please don't let this degrade into some kind of flame war as if I'm arguing
against XML, or that direction, or MS in general. I'm ONLY arguing against
making things unnecessarily complex, which I believe XML config often does.

Nov 15 '05 #14

P: n/a
Daniel Billingsley wrote:
Ok, I wanted to ask this separate from nospam's ridiculous thread in
hopes it could get some honest attention.

VB6 had a some simple and fast mechanisms for retrieving values from
basic text files, which in turn could be simply and easily maintained
with notepad.

I understand the benefits of XML, really, but in the case of
configuration files it seems it is almost always nothing more than
unnecessary complexity, both in accessing them and maintaining them.

What am I missing?


thanks for a very good interesting post. I am speaking as a (you could
say) "wannabe developer" in c# so I do not talk as someone with a great
authority on the subject :?)
I must admit to agreeing with you that the arguments against simple ini
files has left me somewhat unconvinced possibly like yourself. I still
remember the days of MSDOS, Lotus123 etc and cant help but feel that
things have gone almost full circle (not a bad thing). One of the
reasons we are told is because of dll hell.
I remember when Microsoft didnt embrace standards but made up there
own, remember the battle between corba and com. Now ms is submitting
standards to the ecma! People would not have believed that 10 years ago.
And I guess as much as people may argue that what we are getting IS an
improvement to what we had, I wouldnt be suprised to see the
reinvention of a light weight registry in 10 years time. I guess what I
am saying is this ...that no matter whether it is an improvement or not
the fact of the matter is that it is here and it is here for the
forseeable future, so we must embrace it where we can.

"You can't say civilization don't advance -- for every war, they kill
you in a new way"
Will Rogers

--

Br,
Mark Broadbent
mcdba , mcse+i
=============
Nov 15 '05 #15

P: n/a
1) Simple things tend to become more complex over time

2) It's easier to use XML than flat files. Why? You want to get the
configuration information into and out of the file, and represent it as
(say) an object in your program. All you have to do is create a
configuration object, mark it as serializable, and then use the built-in
serialization services to save and load it's state. Just a few lines of
code. No nasty parsing. No config/object mapping - everything is done for
you.

Eric

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:uT**************@TK2MSFTNGP12.phx.gbl...
We don't disagree - I said quite clearly that config files are *typically*
fairly simple, but acknowledged XML is obviously better for more complex
situations.

Of course, we're talking theoretically here. I would be curious to see what percentage of .NET apps have config files this complex vs. the kind that
could easily be handled by a flat text file.

I find your point about breaking flat text files interesting because for
simple configuration information I see a 6-line file with all kinds of XML
tags much more prone to maintenance problems than a simple 1 or 2 line flat file.

I don't think we need to keep going 'round and 'round on this. I made this comment because I saw a *few* valid points in another thread which claimed
something like OO principles and n-tiered applications were the work of
satan. Obvious nonsensical drivel. I do, however, personally know of some OO purists that always tend to make simple projects 10 times more complex
than they need to be, which in the long run costs somebody money.

So my point here is I just that this is an example - I think (with no
empirical evidence, of course) there are more cases than not that making
config files XML added unnecessary complexity. Could .NET have supported
both (without the VB namespace hack)? Hmmm.
"Dennis Redfield" <de*************@acadia-ins.com> wrote in message
news:OQ****************@TK2MSFTNGP10.phx.gbl...
I beg to disagree. Configuration files can be quite complex.


<snip>


Nov 15 '05 #16

P: n/a
Ok, more of the same arguments why XML config files are better for some
purposes. I think there's not much point to this conversation.

"Eric Johannsen" <no*********@johannsen.us> wrote in message
news:hE******************@newssvr25.news.prodigy.c om...
1) Simple things tend to become more complex over time

2) It's easier to use XML than flat files. Why? You want to get the
configuration information into and out of the file, and represent it as
(say) an object in your program. All you have to do is create a
configuration object, mark it as serializable, and then use the built-in
serialization services to save and load it's state. Just a few lines of
code. No nasty parsing. No config/object mapping - everything is done for you.

Eric

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:uT**************@TK2MSFTNGP12.phx.gbl...
We don't disagree - I said quite clearly that config files are *typically* fairly simple, but acknowledged XML is obviously better for more complex
situations.

Of course, we're talking theoretically here. I would be curious to see

what
percentage of .NET apps have config files this complex vs. the kind that
could easily be handled by a flat text file.

I find your point about breaking flat text files interesting because for
simple configuration information I see a 6-line file with all kinds of XML tags much more prone to maintenance problems than a simple 1 or 2 line

flat
file.

I don't think we need to keep going 'round and 'round on this. I made

this
comment because I saw a *few* valid points in another thread which claimed something like OO principles and n-tiered applications were the work of
satan. Obvious nonsensical drivel. I do, however, personally know of

some
OO purists that always tend to make simple projects 10 times more complex than they need to be, which in the long run costs somebody money.

So my point here is I just that this is an example - I think (with no
empirical evidence, of course) there are more cases than not that making
config files XML added unnecessary complexity. Could .NET have supported both (without the VB namespace hack)? Hmmm.
"Dennis Redfield" <de*************@acadia-ins.com> wrote in message
news:OQ****************@TK2MSFTNGP10.phx.gbl...
I beg to disagree. Configuration files can be quite complex.


<snip>

Nov 15 '05 #17

P: n/a

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:Oy*************@TK2MSFTNGP11.phx.gbl...
You folks are arguing for the need for XML config files in some cases, which I've already admitted several times. I guess I should have made the subject "why no more flat config files" to better represent my question.

In regards to supporting both simple flat files and XML files, I don't buy
the argument that it makes things too complicated. It doesn't seem any more complicated to me than having to be aware of the way search paths worked in DOS 6.22 or the way a web application can have multiple config files
scattered across several folders creating a complex hierarchy of config
settings. The rules would be quite simple:
1) look in a flat text file named xxx
2) look in the config file named xxx
3) XML takes precedence on conflict

The complexity comes down to support. Simply because flat files are
possible, support personnel needs to be able to walk the end user through
whatever configuration method you use, it could come down to what the
administrator felt like using, that is complexity defined.
Also, it requires extra classes, it adds the potential that you walk into a
situation where you have to scrap your config file because you need to store
hiearchal data.
Standardization has a point, and picking ONE format to use was needed. In
this case xml provided a much better solution overall, even if sacrificing
simplicity in the bottom 10% of cases.
Just think of a case where your config files only has one setting and you're on the phone with a user of your software and you're trying to get them to
turn on verbose logging in the config file to track down some obscure bug... would you rather have to walk the typical end user through changing a file
with one line

Logging=0
to
Logging=3

or have to get them to make the right change in an XML file. I'd take the
former any day. This is an example where the complexity of XML will
undoubtedly cost people money.
I'd rather tell them how to do it in XML than have to ask them:
"Ok, sir, does your app.config start with <?xml > or does it start with
something else?"
"the xml one"
"Ok, xml, then do this..."

or,
"something else"
"ok, it doesn't, then do this".

why does 2 possibilities make things better? Most end users I've been in
contact with can't handle sectioned ini's very well either.

In fact, now that I think of it, the beauty of supporting both would be you could put a few basic things like that in the .ini file and the more complex stuff in the XML file ..
Which is a waste, one file, one config. No need to add a bunch of extra
logic and more complicated instructions simply because it lets you have a
flat file.

As for .ini and registry being legacy, I think that is kind of a
self-defeating argument. We've been told for 5 years the registry was
supposed to make config files obsolete, and here we trying to get away from the registry as much as possible and go back to config files. Maybe I'm
just an ornery old fart, but I'm very skeptical of the latest greatest new
directions from MS being the final word.
I considered the registry to be much better than the annoying proprietary
configuration file formats. However, with the evolution of xml and a
standardized, fairly easy to read syntax, I no longer think that the
registry is a as nessecery device.

The "reinventing the wheel" argument is interesting too in that regard,
since XML config files is I guess the 3rd version now. I agree it's a good reinvention, but that argument isn't logical - as if leaving flat file
support in .NET would have been a 4th version. No, it was the 1st. Yes, it would be unwise of me to write my own flat config file support at this
point, but that's quite a different thing from MS leaving it in .NET.

Yes, there are reasons why XML config files are a great thing, but that
ain't two of them.
I disagree. INI files are still annoying. Explaining to people how to work
with sections was too complicated, and they are to inflexible.

I do wonder why flexiblity is not a good thing about xml however?
Now, the international/unicode argument is an interesting one. I wonder how big the impact of that is though, from the standpoint of number of projects it effects. Since XML is in reality a simple text file, how does it solve
that problem?

Basically, standardized encoding specifier. Plain text files don't reliably
specify an encoding. You simply have to assume its the proper encoding.
Thats basically xml's strong point.
Please don't let this degrade into some kind of flame war as if I'm arguing against XML, or that direction, or MS in general. I'm ONLY arguing against making things unnecessarily complex, which I believe XML config often does.
I'd rather not start a flame war either, I simply disagree with your stance.
I think in the end, xml config files reduce overall complexity by providing
a standard format that the entire framework works with, while flat files
could only be used in limited situations.

Nov 15 '05 #18

P: n/a

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:e9**************@TK2MSFTNGP12.phx.gbl...
<snip> Also, it requires extra classes, it adds the potential that you walk into a situation where you have to scrap your config file because you need to store hiearchal data.
Standardization has a point, and picking ONE format to use was needed. In
this case xml provided a much better solution overall, even if sacrificing
simplicity in the bottom 10% of cases.
By that logic we should only have ONE mechanism for remoting (HTTP or TCP),
only either DataSet or DataReader, or one database supported by ADO.NET,
etc. ad infinitum. God forbid we should have to switch between two options!
There are a gazillion cases where having multiple ways of doing things
obviously adds complexity to the developer that must understand them all, or
at least choose one of them. But we accept and embrace them because then we
can pick the one that works best for the particular situation given that the
options each have certain strengths and weaknesses. What's the difference
here?

I'd rather tell them how to do it in XML than have to ask them:
"Ok, sir, does your app.config start with <?xml > or does it start with
something else?"
"the xml one"
"Ok, xml, then do this..."
Uh, I would think the person/company who wrote the application ought to know
where they put the setting in question.
why does 2 possibilities make things better?
Uh...
.
Which is a waste, one file, one config. No need to add a bunch of extra
logic and more complicated instructions simply because it lets you have a
flat file.


See above.
Nov 15 '05 #19

P: n/a

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:OL**************@TK2MSFTNGP10.phx.gbl...

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:e9**************@TK2MSFTNGP12.phx.gbl...
<snip>
Also, it requires extra classes, it adds the potential that you walk into a
situation where you have to scrap your config file because you need to store
hiearchal data.
Standardization has a point, and picking ONE format to use was needed.

In this case xml provided a much better solution overall, even if sacrificing simplicity in the bottom 10% of cases.


By that logic we should only have ONE mechanism for remoting (HTTP or

TCP), only either DataSet or DataReader, or one database supported by ADO.NET,
etc. ad infinitum. God forbid we should have to switch between two options! There are a gazillion cases where having multiple ways of doing things
obviously adds complexity to the developer that must understand them all, or at least choose one of them. But we accept and embrace them because then we can pick the one that works best for the particular situation given that the options each have certain strengths and weaknesses. What's the difference
here? Thats a very weird set of ideals. In some cases, HTTP or TCP is annoying and
hopefully will be less of an issue in the future. However, DataSet and
DataReader are vastly different things. Flat files and xml files would be
the same thing in a different format, there really is no parallel here.
Btw, you've yet to provide ANY proof that flat files are useful. All you've
done is complain about a pervcieved increase of complexity. Do you have any
argument for supporting flat files, or is it just that you don't want to
upgrade(or aren't willing to actually try to learn something maybe?) You
have, however, argued that increased flexibility is not a reason to not use
flat files, what exactly is it that you want?

I'd rather tell them how to do it in XML than have to ask them:
"Ok, sir, does your app.config start with <?xml > or does it start with
something else?"
"the xml one"
"Ok, xml, then do this..."
Uh, I would think the person/company who wrote the application ought to

know where they put the setting in question.

Ok, then, what if the end user administrator needs to use advanced, non-flat
file capable features like remoting configurations or assembly redirections.
That means that the xml file would have to be used and both would have to be
supported by the developer to provide an acceptable classes.
why does 2 possibilities make things better?


Uh...
.
Which is a waste, one file, one config. No need to add a bunch of extra
logic and more complicated instructions simply because it lets you have a flat file.


See above.


Of course, your proving my point. One thing is simpler, in the cases above
there are valid reasons for the variety of choices, even if it increases
complexity. On the other hand I don't think there is a valid reason for flat
files, they don't provide anything, no new features, no ease of working
with, it just takes a way flexibility without adding anything to the mix.
Why bother? Why not store all of your data in ini's for that matter, forget
xml or databases, just use flat files.

Nov 15 '05 #20

P: n/a
I've changed the subject as I suggested a few posts ago because my original
title doesn't truly reflect my question or position.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:eQ**************@TK2MSFTNGP12.phx.gbl...
Thats a very weird set of ideals. In some cases, HTTP or TCP is annoying and hopefully will be less of an issue in the future. However, DataSet and
DataReader are vastly different things. Flat files and xml files would be
the same thing in a different format, there really is no parallel here.
I'll grant you the DataSet/DataReader argument, but you know full well there
are countless cases where there are equivelent ways of doing things. Your
argument would call for a complete rewrite of the entire framework - numeric
type conversions is just the first example off the top of my head. Or how
about += or ++ operators? I can't count the number of times I've heard
seminar, MSDN, magazine writers, or even posters in this newsgroup say
something to the effect of "one of the things about .NET is it gives you
several ways to do things." You'll have to be a little more intellectually
honest with your arguements I'm afraid.

Btw, you've yet to provide ANY proof that flat files are useful. All you've done is complain about a pervcieved increase of complexity.
You obviously haven't read, or can't understand, what I've written so far.
Ok, then, what if the end user administrator needs to use advanced, non-flat file capable features like remoting configurations or assembly redirections. That means that the xml file would have to be used and both would have to be supported by the developer to provide an acceptable classes.
Not how to translate "to provide an acceptable classes" means, but yes,
we're talking about supporting both. Just like you must understand the
significance of numerous web.config files that may contain duplicate values
or the fact that you can add trace listeners in a config file or within the
program itself, or what += means, etc. etc. etc. etc. - all "complexities"
we embrace because we like the flexibility multiple options provide.
Of course, your proving my point. One thing is simpler, in the cases above
there are valid reasons for the variety of choices, even if it increases
complexity. On the other hand I don't think there is a valid reason for flat files, they don't provide anything, no new features, no ease of working
with, it just takes a way flexibility without adding anything to the mix.
Why bother? Why not store all of your data in ini's for that matter, forget xml or databases, just use flat files.


You have some interesting logic flow there Daniel. Having two options
"takes away flexibility"? You can't admit one single advantage of flat
files. You are even arguing here that maintaining a single key=value file
isn't never easier than a 5-6 line nested tag XML file. You are so hung up
on the argument that XML files are better for some cases, to which I've
readily agreed throughout this thread, that you apparently can't admit
there's a single situation where a flat file would be better, even
theoretically speaking, and have resorted to pure childishness here at the
end, as if I ever even hinted that I think there was not a need for XML
files in general.
Nov 15 '05 #21

P: n/a
BTW, this is kind of off topic, being more of a general .NET issue, and I
think everybody has expressed their opinion, so you can take your best shot
back at me but then I think this has run its course.
Nov 15 '05 #22

P: n/a

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:ei**************@TK2MSFTNGP11.phx.gbl...
I've changed the subject as I suggested a few posts ago because my original title doesn't truly reflect my question or position.

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:eQ**************@TK2MSFTNGP12.phx.gbl...
Thats a very weird set of ideals. In some cases, HTTP or TCP is annoying and
hopefully will be less of an issue in the future. However, DataSet and
DataReader are vastly different things. Flat files and xml files would be the same thing in a different format, there really is no parallel here.


I'll grant you the DataSet/DataReader argument, but you know full well

there are countless cases where there are equivelent ways of doing things. Your
argument would call for a complete rewrite of the entire framework - numeric type conversions is just the first example off the top of my head. Or how
about += or ++ operators? I can't count the number of times I've heard
seminar, MSDN, magazine writers, or even posters in this newsgroup say
something to the effect of "one of the things about .NET is it gives you
several ways to do things." You'll have to be a little more intellectually honest with your arguements I'm afraid.

Btw, you've yet to provide ANY proof that flat files are useful. All you've
done is complain about a pervcieved increase of complexity.


You obviously haven't read, or can't understand, what I've written so far.


No, I simply think you are wrong.
Ok, then, what if the end user administrator needs to use advanced,

non-flat
file capable features like remoting configurations or assembly

redirections.
That means that the xml file would have to be used and both would have to be
supported by the developer to provide an acceptable classes.
Not how to translate "to provide an acceptable classes" means, but yes,
we're talking about supporting both. Just like you must understand the
significance of numerous web.config files that may contain duplicate

values or the fact that you can add trace listeners in a config file or within the program itself, or what += means, etc. etc. etc. etc. - all "complexities"
we embrace because we like the flexibility multiple options provide.
Of course, your proving my point. One thing is simpler, in the cases
above there are valid reasons for the variety of choices, even if it increases
complexity. On the other hand I don't think there is a valid reason for

flat
files, they don't provide anything, no new features, no ease of working
with, it just takes a way flexibility without adding anything to the mix. Why bother? Why not store all of your data in ini's for that matter,

forget
xml or databases, just use flat files.


You have some interesting logic flow there Daniel. Having two options
"takes away flexibility"? You can't admit one single advantage of flat
files. You are even arguing here that maintaining a single key=value file
isn't never easier than a 5-6 line nested tag XML file. You are so hung

up on the argument that XML files are better for some cases, to which I've
readily agreed throughout this thread, that you apparently can't admit
there's a single situation where a flat file would be better, even
theoretically speaking, and have resorted to pure childishness here at the
end, as if I ever even hinted that I think there was not a need for XML
files in general.
Let me rephrase. To support flat files across all situations, flexibility
would have to be sacrificed. It would, infact, press the design of
configuration and its organization into things only expressable by flat
files, otherwise you end up with cases where you have to rewrite your config
file because you hit upon a situation, possibly a rare situation, where the
flat file doesn't do what you want. Now, speaking as an end user, config
files aren't my favorite things to begin with, now throw in that maybe I'll
have to start with a blank slate and rewrite it because the author was
concerned that I couldn't handle xml? That would just piss me off in the
end.

Nov 15 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.