#190 libxml2 requirement replacement
As was discussed in the -devel group here's the patch that is a simple backup
to read and write fuse configuration file in case libxml2 is not available.
(http://sourceforge.net/mailarchive/forum.php?thread_name=5643.206.64.224.128.1232058856.squirrel%40poczta.webtech.pl&forum_name=fuse-emulator-devel)
It was discussed that the group that those functions should be in compat/ and
replaced with native functions wherever available. Since I didn't have time to
move that out of settings.c, the functions are in settings.c (or more precisely
settings.pl).
The replacement functions use .ini file like syntax (without sections). They
work well independently of the newline character (\n, \r\n or \n\r), whether
there are extra leading or trailing spaces or tabs in lines.
The diff generation against /trunk/fuse revision 3969.
To patch run
patch -p0 < configuration.diff
in fuse directory.
I hope it is accepted as is for now. If someone has time to refactor the patch
to move the functions into compat/ they are welcome to.
patch
Looks better than our current hard requirement for libxml in order to save settings despite not being ideally separated off into the compat directories, so I think we should go for it.
Thanks Fred,
I was thinking about moving it to compat, what if there's a chance that this will replace the libxml2 dependency altogether? Most rc files in unix resemble ini files rather than xml files anyways and also what if we come to a point where it would be useful to be able to copy the rc file from one platform to another...
The argument for not moving it into compat is, if in future the libxml2 dependency is removed altogher, it would also make sense to move this patch out of compat again. So if it's not causing a problem, I would lean towards leaving it as is.
The Mac port will always use the native preferences framework, so there will always be a platform difference in this area. Also an impediment to just copying settings files around are file paths and the like which will differ per-platform.
Phil has already had a patch and an opportunity to switch to an ini file type format in the past, so I think his preference will remain with the XML version by default.
BTW. is there any advantage of using XML (like) config file?
IMHO just a lot of disatvantage:
- external library
- needless memory consumption (the ini file parsing can be done practically with no memory usage)
- needless time consumption of config file parsing (ok. this is a theoretical "problem" :)
- a simple text config file is far better editable with a text editor...
I agree with your list of disadvantages for the XML config file, but there is at least a couple of advantages; no need to write parsing routines which are often error-prone and support for more complex data structures without drama.
Marek - is there any reason that you didn't commit this patch?
Yes - I wanted to move it into compat as requested. Just didn't have a moment to do that yet.
"...write parsing routines which are often error-prone" - IMHO there is no any complex parsing rule in fuse config so it can be done even easy and clean scanf()s
"...support for more complex data structures" - IMHO fuse does not need complex data structures (max 'var = value' :)...
btw. with glib2 we can easily implement 'complex' lexical scanner if we need complex data structures...
I looked into moving it into compat and IMHO it would be a mess. Both xml and ini parsing routines use perl to generate the source file (settings.c from settings.pl). So in order to move the ini part into compat, I would have to pretty much copy most of settings.pl into a new perl file inside compat/ (rename it appropriately) and build a source with that perl inside compat. This would duplicate a lot of code and IMHO unnecessarily make the overall code larger. Please let me know if you disagree, but at this point 2 best solutions are: commit this one as is or rewrite routines handling settings to accommodate plugin-like architecture (just to handle xml and ini). So I would lean towards committing this patch as is, but I would like to know your opinions on it before I do that...
Of course there are 3 variations already as the Mac OS X port has a native replacement for libxml, so there are 3 different backends rather than two.
However, as I said in the first comment "Looks better than our current hard requirement for libxml in order to save settings despite not being ideally separated off into the compat directories, so I think we should go for it."
committed in revision 4071. thank you all for your input.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).