Configuration files

b.zaar · Post by **b.zaar** » Sat Jan 25, 2014 3:47 am

Well I'm not at the stage to need it yet but today I was thinking about configuration files. I'm thinking about how to handle files and their associated programs. The system will be a database in memory that reads a configuration into the database for the supported file types. The configuration files will be read on a need to know basis so that file types that are rarely used wont have a database entry until that file type is loaded from the shell. Programs can load any type of file without affecting the database, this system only affects files that are opened by the user from a file shell like double clicking a png file.

The configuration files will be stored in the file system in the following way:

Code: Select all

sys/config/ftypes/
    html.id
    htm.id -> html.id        # A filesystem link to another file type
    jpg.id
    png.id
    txt.id

so that if the entry isn't found in the database in memory it will load the entry from the ext.id file.

What I wanted to know is what type of configuration file would be the most useful?
I started with a design using something like a shell script:

Code: Select all

txt.id:
    #! bin/syscfg ftypes
    # Header ID
    head.id = ""        # Text files have no defined header

    # Commands
    cmd.open = "textview $1"
    cmd.edit = "textedit $1"

jpg.id:
    #! bin/syscfg ftypes
    # Header ID
    head.id = ?,?,"JFIF"        # If the first 6 bytes do not match then this entry is ignored

    # Commands
    cmd.open = "picview $1"
    cmd.edit = "picedit $1"

png.id:
    #! bin/syscfg ftypes
    # Header ID
    head.id = 137, 80, 78, 71, 13, 10, 26, 10        # If the first 8 bytes do not match then this entry is ignored

    # Commands
    cmd.open = "pngview $1"
    cmd.edit = "pngedit $1"

With this example the usual sha-bang loads bin/syscfg and the parameter ftypes as the table to set. The settings for the file type are then entered into the configuration table.

The other option I considered was XML with the following layout:

Code: Select all

txt.id:
	<ftype media:"text/plain" ext="txt">

		<!-- No head entry because text files have no defined header -->

		<action>
			<cmd open="textview $1"/>
			<cmd edit="textedit $1"/>
		</action>

	</ftype>

# This entry could appear in a default.id file that includes defaults for a number of different file types and is loaded when the system is initialised
image.id:       
	<!-- default action for all images -->
	<ftype media:"image">
		<action>
			<cmd open="picview $1"/>
			<cmd edit="picedit $1"/>
		</action>
	</ftype>

jpg.id:
	<ftype media:"image/jpeg" ext="jpg;jpeg">

		<head>
			<id>?,?,"JFIF"
			</id>
		</head>

		<!-- Use default image actions -->

	</ftype>

png.id:
	<ftype media:"image/png" ext="png">

		<head>
			<id>137, 80, 78, 71, 13, 10, 26, 10
			</id>
		</head>

		<action>
			<cmd open="pngview $1"/>
			<cmd edit="pngedit $1"/>
		</action>

	</ftype>

The second example makes use of media types and uses a default value for handling files that do not need special commands. The question is which type of configuration would be natural (to programmers mainly) and is there a different file format like JSON or YAML that would be preferred?

The format would be used for all configuration files loaded to the system database so the user and group files would be similar in XML:

Code: Select all

users.cfg:
    <user id="user1" password="1%34timeocg12f4gygu" name="First user">
        <attrib>
            <something>This is something that this user has, but not all user have</something>
        </attrib>
    </user>
    <user id="user2" password="aehn234%&gpgjk" name="Another user"/>
    <user id="user3" password="atn.ud@#g,'.k" name="This user"/>

Jezze · Post by **Jezze** » Mon Jan 27, 2014 10:52 am

You are way ahead of most people here so youve probably thought about this more than us. All I can add is that it was really easy and powerful for me to just have all configuration being set directly to the kernel through a /dev type filesystem and from userspace have a simple scripting language like bash.

Owen · Post by **Owen** » Mon Jan 27, 2014 11:30 am

Look at how Mac OS X does it (with registrations inside the Info.plist file inside the application bundle)

Its my favorite method, because it contains all the filetype registrations for an application inside the application.

bluemoon · Post by **bluemoon** » Mon Jan 27, 2014 2:29 pm

By the way, the old fashion extension registration is too limited for modern usage, and it does not resolve conflicts.
Consider you have an .html file, would you open it on a browser or HTML editor?
Mac OS X also do a good job here by allowing you override the handler for a specific file.

Consider now there are protocol handlers(ssh://, git, http, sftp, etc), and perhaps multiple handlers available for same mime type / protocol. You would end up in a mess like window's shell ext registration if you overlook them.

b.zaar · Post by **b.zaar** » Tue Jan 28, 2014 2:43 am

Jezze wrote:You are way ahead of most people here so youve probably thought about this more than us. All I can add is that it was really easy and powerful for me to just have all configuration being set directly to the kernel through a /dev type filesystem and from userspace have a simple scripting language like bash.

That was my first option to use a script. It seems straight forward and easy enough but I dont want it to be limited in functions because of it's simplicity. The configuration files would be stored in a similar way with a /config filesystem that loads drivers, users, groups and most other system settings. The in memory system would probably be a database using sqlite but that's just one idea.

Owen wrote:Look at how Mac OS X does it (with registrations inside the Info.plist file inside the application bundle)

Its my favorite method, because it contains all the filetype registrations for an application inside the application.

That seems like a good option, something I'll have to look at in detail and it looks like it's using XML which was the second option I considered and preferred.

bluemoon wrote:By the way, the old fashion extension registration is too limited for modern usage, and it does not resolve conflicts.
Consider you have an .html file, would you open it on a browser or HTML editor?

This would depend on the user's preferences as the options can be changed and saved. The first command would be a default action like open or edit and a right click menu would have as many commands as the user has set for that file type. File extensions are still useful for simple operations but they don't have to be a limited size anymore. My file association system looks inside the file to check it is a valid file of the type it's expecting.

bluemoon wrote:Mac OS X also do a good job here by allowing you override the handler for a specific file.

How does it do this? I'm not a Mac user so I haven't seen this. Do you mean you can change the action from open to edit permenantly or it changes when you open it with a right click or shift-click or something?

bluemoon wrote:Consider now there are protocol handlers(ssh://, git, http, sftp, etc), and perhaps multiple handlers available for same mime type / protocol. You would end up in a mess like window's shell ext registration if you overlook them.

This is something I haven't considered yet. Maybe the program using the protocol would handle the file until it is stored to the filesystem or it could be shared as a network filesystem which would then handle it as a normal local file.

My main thought at the moment was the file format of configuration files. As far as hand coding configuration files that could also be written back to by the sysconfig program, is there a good standard already out there? Since posting this topic I've read a few pages giving the thumbs down to XML. I liked the idea of XML but I'm not going to use it if it's detested by a majority of programmers.

OSDev.org

Configuration files

Configuration files

Re: Configuration files

Re: Configuration files

Re: Configuration files

Re: Configuration files