Actually, I think it fits ReGrid better than Connect.
I had almost felt like suggesting that we form some kind of
committee, but then I thought--I don't have time to offer and I don't
want to see things bogged down in a committee anyway.
I did have a new thought. What if we added a new branch in the cvs
tree named vap. It would be the value-added-pack that non-beginners
could get and compile with DX. We could set up a branch with just the
additions that could be checked for at compile time or set it up so
that the whole branch compiles all the modules as loadables (or
something). That way if the user doesn't get the vap they still have
the standard core. This could also be used as the testing bed and if
at some point in the future everyone decides that a certain module
should be moved to the core it would be quite easy.
What do you say to that? I would be willing to work on the autoconf
code to handle this.
David
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
--
.............................................................................
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
