[GD-General] RE: A portable preferences library

[Jeff L. <je...@SP...>]

> I agree with Brian; I want to be able to delete an application 
> directory (or perhaps one day it will be an archive object) and 
> have it gone -- without the operating system being involved in 
> anything other than a file deletion operation.

whereas I want to be able to delete the application (the hundreds of MB) but
keep my save games and keystroke preferences so that in six months time when
I load the game back (as I did recently with Quake), its all still there.

You are *not* going to keep everyone happy in this space.

> On the subject of multiple instances of an application versus the
> ability to double-click to open documents...  Okay, this feature
> would require a list of file extensions and paths to associated
> applications, which I assume is currently found in the Registry.
> [snip]
> Microsoft may have used something called a Registry file for 
> this purpose

I have to admit, this sounded spookily like you don't know how Windows works
at all, which sort of skews the value of some of the opinions being offered.

(End of unintended offense)

> As far as I'm concerned, this is not compromising my philosophy.
> The window system is an application with its own "preferences",
> such as what application to use to open a given file extension.

Actually, its the Explorer or more correctly the "Windows Shell" that has
this preference, but other applications can and do look into that space, a
big advantage to having a semi-wellknown globally readable repository/format
for your preferences.

(Again, in our non-game application we do exactly this - sometimes we need
to mess with another app, and we don't really want to know where its been
installed, we just ask Windows "who would open this document type if we
double-clicked on it" and it gives us back the full pathname to the
appropriate app.  We don't launch it, we just exploit the fact that we found
it without having to deal with searching file systems for filenames that are
different depending on native language, etc)

> Microsoft may have used something called a Registry file for 
> this purpose -- but I don't see why all other applications on 
> the computer should be considered subordinate (in the sense of
> "being part of") to the Microsoft window system application.

Not subordinate.  Consistent with.  Consistency is a good thing when you are
trying to work out whats gone wrong with someone elses app.  If they do the
same thing as everyone else, they are a lot easier to debug.

> 	Somehow I doubt there are many fathers who are running serious
system-level
> multi-user setups at home.  More likely everyone just uses the same login
> and shares the same clutter.  Sure, it's still multi-user, as in "used by
> multiple people", but not at the registry level.

Hmmm, I'd invite you to my place, or my brothers, but we're probably a bit
far away.

I definitely have multi-user setups which are intended precisely to stop the
5 year olds from messing stuff up.  In my brothers case, its our mother the
65 year old that he protects the system from.

Now, we happen to be the computer literate ones in the family - there is
absolutely no reason why you can't swap father/child in any of this
discussion, as is the case with my brother.  He does the admin, and the
parents use a "nice safe, difficult to break" system.

> In fact, I bet that going forward that higher security privileges and 
> multiuser configurations will become more important.  One of the most 
> common sources of spyware/virii are random things that kids download 
> off the internet -- I'm amazed how many people will "click here" just 
> because something says "CLICK HERE!" 

Ask a security zealot what they think of MacOSX these days - just about
anything downloaded from the net says "ok, authorise me as root" without
giving users a clue about what they are actually allowing.

> Originally I was thinking it would be a binary file format, strictly 
> because I wanted the ability to serialize raw binary data "just in 
> case".  Now you could make a valid argument that you could always 
> convert to text, i.e. 3.14 becomes "3.14", but maybe you don't want to 
> suffer a data conversion loss or something, I dunno.
> 
> Point being that I'd rather not dictate policy if I don't have to.

You need to make your mind up on whether you think prefs files are movable
across architecture or not?  If they are, then float-format will kill you,
as will endianness in integers.

Personally, I think that floating point *prefs* are going to be pretty damn
weird to start with, and you need to keep in mind that that information is
entered either as text (ie, in an EDIT control), or by tweaking a scrollbar.
In either case, the user can't really complain about that last bit that
might go wrong in the ASCII->FLOAT conversion.

I'm surprised that no-one has said "use XML format please" - its not that
painful, given that you'll have a fairly limited schema to implement.