I've been watching the discussion here without commenting to try to get an idea of the community's feeling about this. I think there's a bunch of issues here. I think there has to be some sort of review process before new features go in. There's a continuum between generally useful modules and modules that solve one person's problems, and the best judge of general utility is probably not the author. I think there's a big downside to module proliferation. I think the set of modules ought to be kept as small as possible so that new users are not daunted by long lists of tools they have to wade through to find the ones they need. At the same time, I would never claim that the current module set is sufficiently complete that no new modules should go in. So i'm not sure how to proceed. In the old days we had a modules committee that decided what should go in, what the parameterization should be etc.
I'm also concerned with documentation. While Chris is right - it was done originally in Bookmaster - its all in html now, isn't it? So I think it can be relatively easily editted, but I'm not sure how it can be printed. Then there's the issue of context-sensitive help. I have no idea how that works. In any event, I think both should be updated if new functionality goes in - particularly new modules that are immediately visible to the user. In this case, I wonder if this new functionality coudn't be added as a different method of Connect? Greg David Thompson <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 01/10/2001 10:45:40 AM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: [email protected] cc: Subject: Re: [opendx-dev] Adding a new module to CVS? Chris, I had Jeff pose these questions to the group because I didn't know the answers. I do know that if this module was included in the distribution it is less hassle than having to teach people to compile the single module, etc. I do have some autoconf magic that I put together for modules but I'd rather see some modules be included (if the author wants to donate them). So these are questions I have as well. 1. If the author is pretty confident in their code but we leave new potential modules separate for testing purposes, how do we get people to test them if they don't want to compile them? 2. If we do keep them separate and I provide my autoconf magic, who's going to teach people how to set it up? Personally, I'd rather see this module added to the source. I was hoping we'd hear from Greg and Peter and get their thoughts. I have some data importers that I'd like to add to the cvs tree as well. By the way, there is a contribution area already at OpenDX.org. Go to the "Addons" section. I've only had one person contribute anything yet. David > > >>Another question I meant to ask was: Should the module even be added to >>CVS? I can certainly make it available through the Univ. of Montana site. >> > > >I think there's something to be said for a "Contributed >Modules/Macros/Tips" Section" at opendx.org. However, for modules, it would >be advantageous if it were automatically compiled when one built opendx, I >suppose. The only thing is whether it should be left separate until a round >of testing has happened, or, since you've had it for a while, are you >pretty confident it runs on all the platforms/OSes that people are >currently running openDX on? > >Chris Pelkie >Vice President/Scientific Visualization Producer >Conceptual Reality Presentations, Inc. >30 West Meadow Drive >Ithaca, NY 14850 >[EMAIL PROTECTED] -- ............................................................................. David L. Thompson The University of Montana mailto:[EMAIL PROTECTED] Computer Science Department http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 Work Phone : (406)257-8530
