Concept of "Data Directory" on each platform

Question

This is very similar to Where should cross-platform apps keep their data?, but expanding on it a bit.

There is some good advice on where the parent directory for data should be, but not so much on what a given app's directory should be.

For example, let's say we have a cross-platform application, written by My Corp, within My Brand, called My App. Assume there are other products in My Brand which presumably want their own data, and other brands in My Corp as well. Where should its data and/or configuration go on Windows? On Unix? Mac OS9? Mac OSX? Other?

e.g., on Windows, would the data go in "...\Application Data\My Corp\My Brand\My App", while on Mac OS X the data would go into ~/Library/Application Support/My Corp/My Brand/My App" and on Unix it would go into "~/.mycorp/mybrand/myapp"? (I would imagine other platforms would use the mangling of unix, even if the base directory may be different.)

If there is no real convention, does this seem reasonable? Any suggestions for Mac OS9?

Answer 1

Just to start the reflection:

You have to make a clear difference between:

• application state data
• settings
• data (can be common for several applications)

The latter may eventually be in a database, or could be managed by one or several applications, or encapsulated by a communication bus in order to avoid all the other applications to dialog between themselves to access those data.

The data representing the state of an application can go in 'Application Data' as mentioned in the question "where cross-platform apps keep their data ?".

But the settings... It depends if you application need to be launched with several "configurations":

• one for each platform: in case you must manage them in the development stage, and package that file in the release stage, in order to store it in 'Application Data'
• many for one platform, like with different Heap sizes, or different settings representing different operations to be executed by your same app. And that leads to an explosion of setting files (also stored in various sub-directory of 'Application Data')
  That is where the idea of abstracting those data into a Setting Provider is a good idea.

Actually, we have so many different configurations for our settings we store them into a database on a separate production machine. That way all the apps can access them, but more importantly, we can access and change them in real time, without having to stop / restart the applications for each modification, or without having to go to each deployment platform.