?

Log in

No account? Create an account
Where should I store config information? - LiveJournal Client Discussions [entries|archive|friends|userinfo]
LiveJournal Client Discussions

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Where should I store config information? [Jul. 27th, 2002|04:54 am]
LiveJournal Client Discussions
lj_clients
[indif69]
[mood |curiouscurious]

Ok, so I'm writing a client. zebjournal. Its in pre-alpha right now and I'll probably be in here asking for beta testers in a week or so. No beta testers yet please.

But I'm thinking where would the best place to store configuration information be? Should I save it to an XML file in the same folder as the client? Should I save it to the Windows Registry? Should I save it to the Application Data Folder? The Local Settings/Application Data Folder? Which one do you think would be best given that I need to store the following?
  • basically the entire login response hashtable
  • Usericons (pictures)
  • Drafts and Downloaded Entries
  • Application Preferences

ZebJournal is supposed to be a 'power-user' LJ client. It has a MDI , multiple journal, and multiple user support across any LJ based site. So the amount of data could get pretty big. Target Platform is Win2k/XP ... I'm not really too concerned with windows 9x, as it is being phased out anyway, and it cannot support alpha-blending which will be used in ZebJournal. No flames from win9x users please.
linkReply

Comments:
[User Picture]From: pyran
2002-07-27 02:36 am (UTC)
I think it depends on how flexible you want it. I wrote a class that stores, retrieves, and serializes options (something I wrote to help me learn .NET that works in any application I write), and I store the config data using that in the same folder as the application (actually, a subfolder named for the user who's using the config options). Using that, the program can be moved at will to anyplace on the hard drive. The only problem with the Registry that I can think of is that if you're storing paths, moving a program to another drive/folder would have to entail Registry changes and wouild probably be a bit on the annoying side. Also, if I remember correctly, the Registry isn't the place for large amounts of information -- I want to say something like >2k should be stored in .INI files or somesuch.

As for the Application Settings folder, that is a good idea. It insures that the application would always know where the data it needs is, but if you're storing a lot of data it could be problematic for people who put their OS on small partitions and their applications on the larger ones.
(Reply) (Thread)
From: indif69
2002-07-27 03:03 am (UTC)
large is a relative term. The total amount of data per user could be no more than 500K excluding downloaded entries. That can go in the Application Data Folder without problems. Uh, for downloaded entries, I plan on saving images in them too, so it could get large really fast. I guess the best thing for me to do would be to add an option as to where to save downloaded entries. Seems like a good idea.
(Reply) (Parent) (Thread)
[User Picture]From: mart
2002-07-28 05:32 pm (UTC)

I'm one of those people, but I have Windows configured to put my "home directory" on my large partition with the rest of my data. I'd hope that anyone else savvy enough to make partitions would have either done that or used NTFS's capability to mount one partition into the filesystem of another.

Anyone who hasn't made arrangements for this must get problems like this frequently, and it's their own fault really. I'd say put it in the directory Windows provides for that purpose, as it makes it easy for users to ship their settings around and back them up without taking with them applications that they could re-aquire relatively easily.

(Reply) (Parent) (Thread)
[User Picture]From: axiem
2002-07-30 01:37 pm (UTC)
Off-topic:

I know how to do the former (configure where Windows puts a user's home directory). However, I've heard of the latter (mounting a partition into the filesystem of another), but have no idea how to do it. Do you have a handy link explaining it or something? I'm curious.
(Reply) (Parent) (Thread)
From: indif69
2002-07-30 02:34 pm (UTC)

Re:

I don't have links, but you do it from the

Control Panel > Administrative Tools > Computer Management > Storage > Disk Management

When you make a NTFS partion, you can select where it mounts.

This is for win2k/XP Pro, I'm not sure about NT or XP home.
(Reply) (Parent) (Thread)
[User Picture]From: axiem
2002-07-30 02:51 pm (UTC)

Re:

Oh, you have to do it when making the partition itself? Heh. I hadn't realized that.
(Reply) (Parent) (Thread)
From: indif69
2002-07-30 06:53 pm (UTC)

Re:

Well, you don't have to do it when making the partition, but both partitions must be NTFS(or at least the one that will be a mounting point for the other one, I'm not sure if you can mount FAT32 on NTFS).
(Reply) (Parent) (Thread)
[User Picture]From: axiem
2002-07-30 10:03 pm (UTC)

Re:

Well, okay. I already have the two NTFS partitions. Just I have no idea where I mount D into C somewhere. (I don't know where menu-wise)
(Reply) (Parent) (Thread)
From: controlg
2002-07-27 03:16 am (UTC)
I'd vote for an XML file in some form. This would allow someone to easily move all settings/data between installations of the client. Having it in the client's directory might not be possible because of permissions and nonadministrative users.
(Reply) (Thread)
[User Picture]From: cyberlizard
2002-07-27 05:57 am (UTC)

You could probably just create an abstract interface to your data, (a node tree for each user, for example). The interface would know where to put each node of data (for example, user login/state info could be stored on the HKLU\ tree, while user icons and whatnot would be stored on disk in a user-specified folder as XML). The key is your program works with the interface and need not worry about where each piece of data is going exactly. Of course, you'd have to figure out how the interface would know where to put data, but that's another story.

Either way, with the user login data and what-not in the registry, your program need not worry where to find its config data when that particular user logs in, and also need not worry about putting stuff in the Application Data folder. With the user icons, entries, etc. being stored somewhere user-configurable, you could offer the Application Data folder as default, and if the user is not satisfied with that, he/she can move it someplace else. Just store the user folder in the registry with the other data.

Well, at least thats how I'd do it. ::sheepish grin::

(Reply) (Thread)
From: indif69
2002-07-27 10:53 pm (UTC)
I like your idea the best. And I am going to implement it, but I'm not going to build the interface right away, that'll be reserved for a later beta. I want it to work first. Thanks :)
(Reply) (Parent) (Thread)
From: evan
2002-07-27 10:09 am (UTC)
On NT+ systems, only the registry protects data from other users if they aren't running NTFS.

You should read the docs on the registry. They say what belogs there and what doesn't.

And it's kinda sad that a journalling client would depend on alpha-blending.
(Reply) (Thread)
From: indif69
2002-07-27 02:32 pm (UTC)
To be honest, the alpha blending is there for the precise reason I don't want to support 9x/ME. Very few 'power-users' actually would use 9x anyway, which is my target audience. And plus, alpha-blending is a nifty feature to have when you're writing a WYSIWYG editor. I could probably do without it, but it just makes my life as the programmer easier. Maybe someone will write a port, it would take a few hours max.
(Reply) (Parent) (Thread)
From: piman
2002-07-27 10:38 am (UTC)
Why do you need to store the login response hashtable? You can regenerate that on every login.

Also, from a UI perspective, MDI is a PITA... I might suggest SMDI/MSDI instead (multiple independent parent windows).
(Reply) (Thread)
From: indif69
2002-07-27 02:35 pm (UTC)
I agree that multiple parent windows would be a great idea, and I am working towards that, but its low on the list of priorities. I'll have a working MDI interface first because its very easy to program in .NET ... Once the backbone is in place, I can refine the interface.
(Reply) (Parent) (Thread)
From: indif69
2002-07-27 02:39 pm (UTC)
Thanks for all your input, if you have something that hasn't been said yet, please leave a comment.

So far it looks like I'll do the following.

I'll store paths for config files and downloaded files in the registry. They will default to the application data folder, but the user can set them in preferences. =) ... If I feel ambitious, I'll write a wrapper for this, make it a little more transparent.

Thanks for your ideas everyone.
(Reply) (Thread)