Gabriele Biffi wrote :
Ryan Leavengood wrote:The only drawback is the resulting settings files are not easily user-editable. But this could be resolved by including a simple "Dumped BMessage Editor" utility for those who want to dig into them. Plus this would be a useful developer tool. I haven't searched BeBits but I suspect there is already applications like that written for BeOS.For config files, I would like to have them text only, maybe in a common format like INI files... or even XML if we want to follow the latest fashion.However, it shouldn't be hard to adapt the Resource Editor for this job. Or using a resource file directly, turning it into a BMessage is fairly easy.
I've always been thinking about the binary/gui vs text config file question, from the programmer and user perspective.
I've accumulated some random thoughts :) Data in plain text pros and cons:1) + the editor is standard, any ascii editor will do the job. Cool for the user and the programmer. 2) + it allows to edit the data like a document or program, ex: you can copy and paste data between two opened editors or a web page, ex2: you can easily compare two files 3) + it allows comments / examples / documentation directly in the file (although plain english ascii can be limiting) 4) - as a user, the editor can't check for you that your changes are syntactically and semantically valid until you throw the config at the corresponding program. 5) - it is hard on the programmer side if you need more than a couple <name,value> pairs. Checking the data for syntax and semantic errors can be difficult.
Well xml could solve part of 4 but with a standard text editor the user can still make mistakes, besides it's harder to read. A specialized xml config format and xml config editor could solve that. On the bright side, xml partly solves 5, but the programmer still needs to define how to organize his xml format and do some high-level work.
Graphical config editors with a file format which implementation is hidden from the user, a.k.a binary file! After all, text is also binary, it's just implemented in english text!) 1) - the editor is not standard. The user might not be familiar with the ui and the programmer need to program check boxes and menus which is not fun. 2) - you cannot edit the data like a document, copying a config from the web or a doc needs you to verify each checkbox or value and their position. 3) ++ as with plain text, it allows comments / examples / doc and much more: menus, tooltips, hyperlinks, presets, multilangage, graphics etc.. 4) + contrarily to plain text, your changes are always valid, the user interface is here to enforce that. 5) + it can be easyer on the programmer because he can use brute force, object/message dumps, and you are sure the data is conform due to 4.
Well, to conclude, i'm dreaming of a config system that would clearly separate the programmer interface, the physical storage implementation, and the user editing interface. From the programmer interface, it would be easy to read/write named data, and meta data like possible values, default values, comments, appearance, help. The storage implementation would be extensible, and could be optimized for memory or speed. The user editing interface would be standard, it could be a stand alone program or an embeddable component for applications. It would automatically build a simple standard interface for the config file and manage validation, defaulting, help etc... If possible it would allow editing, comparing etc as in point 2).
In the mean time, using BMessages and a standard editor would be quite nice :) +1 Ryan
Regards, Alex
