[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] New manual format
>>>>> "Kern" == Kern Sibbald <kern@xxxxxxxxxxx> writes:
>> More of a joke, but I'll ask anyway: have you considered a messages and
>> codes manual? I know I'm being old-fashioned and mainframe-y and all
>> that , but it'd be really helpful to be able to look up a message and
>> know what component it related to and maybe some reasons that would
>> cause that message. I don't see anywhere obvious in this structure where
>> I'd look for that kind of information. It'd be a real help to the
>> translators too, I'd bet.
Kern> Yes, I have considered a messages and codes manual, and in the
Kern> beginning all the messages had unique code numbers. Again, the
Kern> problem is the work required to implement it, and particularly
Kern> to keep it up to date as messages are added and changed. No
Kern> doubt it would be good to have such a manual, and probably one
Kern> day it will exist.
Kern> In any case, I am beginning to work on an entirely new manual
Kern> that will serve as the first part of a training course as I
Kern> think it is something critical for promoting Bacula within
Kern> enterprises ...
>From looking at the source code to 2.2.8, I find it hard to find all
the various commands, especially .<command> versions and what
arguements they take.
Maybe it's time to think about centralizing all the definitions of
commands and such so that it's easier to manage and find and document
I also find it annoying that when using bconsole it doesn't give back
useful error messages if you get a command wrong, it just spouts back
"Missing arguements" or other vague messages.
And since you can't do anything like '<command> ?' inside bconsole to
show you what args the command takes, it's even more frustrating at
I've been looking at the 2.2.8 code today to try and figure out all
the .<command> and how they work, and having them scattered all over
the place is just frustrating.
Maybe it's time people sat down and came up with the definitions of
the commands and their arguements and what they produce for output and
errors, and *then* implement them?
I know, I've said before that I'd like to writeup a 'bcli' which would
show the commands as I think they should be organized. So I'll shutup
now and start putting my nose to the grindstone and coming up with
Anyone else interested in helping out?
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list
This mailing list archive is a service of Copilot Consulting.