>>> On 7/2/2008 at 5:22 PM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > The following proposed patch for stable 3.1, removes all references to C/C++ > as a supported language for building DSO metrics as it was meaningless and > only relevant when used with scripted metric modules. > > It simplifies the code by making "language" an optional parameter and > includes > feedback from Brad into the documentation. > > Contains changes from r1490 and r1500 > > Carlo > ---
-1 The more I look at this, the more I would rather that the changes be reverted and we just leave it alone. AFAICT, the only issue here is whether the "/C++" portion of the language label "C/C++" is misleading enough to cause a developer to waste a significant amount of time attempting to write a module in C++ only to find out that it can't be done today. Since this language label only appears as an optional parameter to the language directive in a module block as well as being referenced in the module configuration documentation of Gmond, I seriously doubt that these references are going to cause any developer serious heartache in the short term. There have already been patches committed to trunk to support the development of a C++ module and these patches have already been proposed for backport in the next minor revision. So all we are really talking about is a very slight misuse of the label "C/C++" between the actual release of 3.1.1 and 3.1.2 which will probably only s pan just a few months at the most. Also to my knowledge, I am the only one that has ever written a "C/C++" class module (so far) and since I am completely aware that developing a module in C++ is not supported yet, I don't believe that we are misleading many developers in anyway. There was an issue raised on the mailing list where a developer was attempting to compile a C language module with a C++ compiler, but the obvious solution was to switch to the correct compiler, not change code and documentation. At the very worst, the choice of the term 'language' as a directive name is really the issue. As I explained before, gmond only supports one interface and that is "C/C++" (yes, C++ is not fully supported today, but will be very soon). All gmond needs to know is if it should handle the module loading or not. The term 'language' was chosen because it seemed like the easiest way to communicate to an administrator what kind of value was expected for this directive. We could have used one of the terms 'Class', 'ModuleClass' or 'ModuleType' rather than 'Language' to accomplish the same thing. It really doesn't matter what the term ultimately is, we just needed some way to inform not only gmond but also every other module interface plugin which module configuration blocks each plugin needs to handle. At the very most, I would consider changing the configuration directive term from 'language' to 'ModuleClass' or 'ModuleType', but that is really all that might need to be done to resolve the issue. As it stands, the term 'Language' is probably good enough and whether the language label is "C/C++" rather than "C", really doesn't matter. Especially after we release 3.1.2. For now I would suggest that we revert the changes and add one sentence to the documentation that simply states that C++ is not fully support yet, but will be very soon. Brad ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
