We have had discussion about dist versions, but what to you thinks of
data files?
Have you version specified in your db/conf/resourses/img files? Any
ChangeLog specially for configs?
Also are you using any data description language for your files?
Now most of software never specify version - they just report parse
error if got some strange symbols...
Better whould be to 1) tell user his config/db file is outdated, 2)
convert to new version.
I have seen in Magick irc-services this behaviour. It has all
load_data() functions from first data-file version,
so it loads anything you give him and saves it using newst format.
Next step is to use data description language. Is there any one except
DTD for XML?
If you look in gated docs - you whould notice style of config commands
description. It is nearly the same,
as normal DD language actually.
If there whould be DD - it whould be easy to write config converters,
migration tools and autoconfig systems
(they could automatically import needed data from existing files, if
they know how to ineterpret them). Also you whould get ability to
"include" system specific configs into programm config
(pkgconfig?).
This could remind you of shell ENV variables :) They are used for this
now. But you couldn't split them in sections - you need to copy all of
them
for every new process. Also you have no standart for them and ability to
partially override them in local ~/.nnn-rc
And note for those. who likes XML :)
It is hard to use XML here. DTD can't specify meaning of
tegs/fields. It could describe interaction between them only
(position, number and parents of Tag) and basic types. If you creating
your own DTD for
actual types(such as OS_VERSION, UID, FILE_TYPE, FILE_LOCATION) which
whould be used to describe conf/data items- that
whould only mean, that you creating your DD language, using XML/DTD. And
still you need to create other parser for interpreting
this new language. It's second level of abstraction. XML will not help
much here....
....if you don't look close enough.
Actually there is a variety of schema languages to choose from already. Your are right, using those you will always create you own DD language - as you would with any other tool.
After all the language is to least extend the syntax. More important is the semantics, which are somehow a property of the parsed tree. With any syntax, XML beeing only an example, you can forget about the parsing and memory representation once you come to the actual purpose of your application.
The is latter mostly, especially for data converters, nothing more than tree transformations. Anybody mumbling XSLT? Actually you can combine persitant stored parsed trees (XML or anything) and tree transformations (whichever language) and have an easy time to get what you ask for. (Askemos)
From a language design point of view, you will always design something like XML. Except maybe you could get the context handling (in XML entity definition) right: they should not be part of the document itself. The reason to go for XML is just the market pressure. Anything else eats more human ressources at these days.
I wrote a client/server application where the config information needed to be stored one per server, instead of one per client. As you can imagine this created a version problem when old clients tried to connect to a server configured by a new client.
I used a MAJOR.MINOR verion number. The MINOR changes when the configuration format is changed but an old client can still read it. In this case the client gets a warning and a message to upgrade when it connects. The MAJOR changes when the format changes in such a way that it will break old clients. In this case the old clients get a message to upgrade when they connect, and then are dropped by the server.
When a new client connected to a server configured by an old client, it would give the user the choice of upgrading the server or disconnecting.
Debian seems to do a bit of versioning(perhaps upstream does too?) in that there are things like XF86Config vs. XF86config-4, and /etc/ssh vs /etc/ssh2. X is a better example of changes in the config structure, I suppose. Tagging your config files with the version when they change majorly seems good enough for most applications.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank