>>>>> "Kern" == Kern Sibbald <[EMAIL PROTECTED]> 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 them properly. 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 times. 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 examples. Anyone else interested in helping out? Thanks, John ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
