Prev: Selecting the font size matching the control's height
Next: Easy question
From: Ralph on 17 Feb 2010 13:52
Tom Shelton wrote:
<snipped>
>
> See, I think we are comming from two different standpoints. When I
> say protable, I mean accross different OS's. Of course, that
> wouldn't matter to you as much - because if you are going to run your
> vb app on another os, such as linux you would have to do so under
> wine - so, your ini would still work. But, if I run a .net app on
> linux, i'm not going to want to do a p/invoke call to the ini apis
> since it will fail. A ini is easy to parse manually of course, but
> again why would I since I have a system already built in?
>
> Belive me, I used to be all about ini files - I still have my INI
> parsing dll around here. I've never been one for the registry - in
> fact, I've pretty much avoided it's use from day one :)

Well, perhaps there are two different standpoints, if one considers having
no clue about what a "text configuration" file really is a 'standpoint'. As
for portablility the "INI" format (Sections, Name/Data pair) came from
mainframes, and can also be found on Unix. It is only one kind of DIFF. It
is as "portable" as anything else out there. That is what it was designed to
be another kind of "portable data information exchange file format".

Windows went one step further and adopted a INI format across the board and
provided a 'system service' for managing them. Not only for use by its own
utilities but available for programmers for use in their own applications.
In this case a step up over Unix, since Unix uses a multitude of
configuration files with diverse formats.

Again, XML has lots of advantages, BUT *portability* or *ease* of use is NOT
one of its exclusive features.

-ralph


From: Tom Shelton on 17 Feb 2010 14:46
On 2010-02-17, Ralph <nt_consulting64(a)yahoo.com> wrote:
> Tom Shelton wrote:
><snipped>
>>
>> See, I think we are comming from two different standpoints. When I
>> say protable, I mean accross different OS's. Of course, that
>> wouldn't matter to you as much - because if you are going to run your
>> vb app on another os, such as linux you would have to do so under
>> wine - so, your ini would still work. But, if I run a .net app on
>> linux, i'm not going to want to do a p/invoke call to the ini apis
>> since it will fail. A ini is easy to parse manually of course, but
>> again why would I since I have a system already built in?
>>
>> Belive me, I used to be all about ini files - I still have my INI
>> parsing dll around here. I've never been one for the registry - in
>> fact, I've pretty much avoided it's use from day one :)
>
> Well, perhaps there are two different standpoints, if one considers having
> no clue about what a "text configuration" file really is a 'standpoint'. As
> for portablility the "INI" format (Sections, Name/Data pair) came from
> mainframes, and can also be found on Unix.

Of course, again that isn't the point. The point was that MOST windows apps
use the windows api to read/write their ini files. Those apis do not exist on
non-windows platforms.

Let's be clear - I'm not saying that the ini format is not portable or easy to
parse... Of course they are. They're text for crying out loud. The problem
is that they are not usually treated that way in code - generally people use
the windows api calls. That's what isn't portable.

> It is only one kind of DIFF. It
> is as "portable" as anything else out there. That is what it was designed to
> be another kind of "portable data information exchange file format".
>
> Windows went one step further and adopted a INI format across the board and
> provided a 'system service' for managing them.

And there you go. It's the system services and the fact that most code calls
those that was what I was refering to. Not to the actual text file.

> Not only for use by its own
> utilities but available for programmers for use in their own applications.
> In this case a step up over Unix, since Unix uses a multitude of
> configuration files with diverse formats.
>

That's the reason I use xml... I have a common format and a common api. I
don't have to change any code. I don't have to compile specifically for the
target os. I can simply run my app as is.

> Again, XML has lots of advantages, BUT *portability* or *ease* of use is NOT
> one of its exclusive features.


Ralph your missing the point... It's not the format of ini - it's the common
use of the windows api calls. If you implment a manual parser, then fine -
it's as portable as anything, but that is not the common usage.

When I use xml in .net then I get a common built in paser for free. I don't
have to waste time coding a manual parser. It's as simple as that.

You and mayayanna are taking those remarks and blowing them way out of
proportion. The fact is I would probably use an ini if there wasn't a common
api already - since I would have to build one anyway, I might as well make it
simple...

--
Tom Shelton
From: Larry Serflaten on 17 Feb 2010 14:58

"Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote


> When I use xml in .net then I get a common built in paser for free. I don't
> have to waste time coding a manual parser. It's as simple as that.

Heretofore, there was a common api for INI, built in to the OS, and later, VB.
Then they moved to XML and (supposedly) dropped support (?) for INI.

So it would seem you are simply using the format 'de jour' where some
later 'incredible advancement' may cause XML to go by the wayside as well.

As you yourself stated, if you already have the parser, then go for it.
As I see it, neither has any great advancement over the other for program
settings. For data transfer, of course, that's a different ball of wax....

LFS


First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Selecting the font size matching the control's height
Next: Easy question