For my job currently I'm using the statistics package R and writing
things using LaTeX.
Both have a very structured method to manage and document addons.
Look at http://stat.ethz.ch/CRAN/ (very good) and at:
http://www.ctan.org/tex-archive/ (less clear).
These could be an inspiration for the future NodeKits structure and
management, I think.
Just my 0.05 CHF
mario
Robert Osfield wrote:
Hi Art,
I understand the issues you talk about. External NodeKit can be
neglected by potential users because they aren't visible enough, and
there are also issue of compatibility and maintenance of these
external NodeKits. It's not just an issue of NodeKits, it applies to
plugins or applications that live around the core OSG project. I
don't think the solution need be a pure software management issue,
it's strongly related to management of website resources.
We've had various different initiatives over the years to try and
address this issue - the wiki is one avenue, another was the formation
of osgforge.org and hosting of several ancilery projects like VPB,
Present3D, osgLua and osgPython. My hope was osgforge would become a
incubator for projects that could make it into the core, or become
part of the close nit family of NodeKits. Such initiatives haven't
thrived as perhaps they could have, partly because the various
contributors haven't pushed things forward, and partly that
wiki/website management takes time and dedicated manpower. I'm open to
suggestions on how better to streamline and manage this side of
things. The bottom line is a key missing ingredient has been
engineers who put the time into keep websites up to date.
As for re-factoring handling of NodeKits in 3.0, I'm open to this. It
might even make the most sense to build 3.0 incrementally, starting
with a re-factored core scene graph and then bit by bit re-introduce
the NodeKits as they get ported across. Quite a few of the older
NodeKits would be best rewritten using shaders, or to be incorporated
into other NodeKits. Having some scheme where 3rd party NodeKits can
be pulled in by end users may well help facilitate a move over to a
3.0.
One thing I have thought about in the past of have an "Open Graphics
Suite" that is collection of related libraries/applications, with a
scene graph one element of the suite, then you'd have extra libraries,
exporters, applications all populate this suite. The suite would
contain optional components that could be selected from to provide the
tools required for different apps. Modern linux packaging
repositories provide this model and the scale of 10's of thousands of
compatible libraries and applications.
Robert.
On Fri, Jan 23, 2009 at 5:34 PM, Art Tevs <[email protected]> wrote:
Hi folks,
The community becames bigger and bigger and there are more and more
projects/nodekits which offers additional features to osg. And therefor I think
OSG 3.0 is the best time to refactor the whole nodekit maintaining structure.
Hence here are couple of ideas, how to do so.
In my opinion, nodeKits/plugins which were not lucky to be included into osg
main core wouldn't survive, because the people would just forget about them.
Making everyday advertisment, that this and this nodekit does provide the
functionality you are looking for is also not the solution. New users are not
used to read wiki pages or search in google, they do not even read ReadMes
which are essential for proper work. They just download and compile the osg and
want to have either an example showing how to do it or try to reinvent the
wheel everytime again and again. Nodekits which are then not included in the
main core (or better say: main download) are not noticed by users.
What I propose is to rearrange/refactor/cleanup osg main core to basic
functionality of a scene graph, so to remove everything which has nothing to do
with a scene graph on its own. Then provide something like official category of
nodekits, where all previuosuly filtered nodekits would be moved. Robert will
became main maintainer, who is responsible for the whole code and for bringing
the category maintainers together. A category maintainer is responsible for his
category and maintainers of each individaul projects which are covered by his
category. The individual maintainer is responsible only for its own project.
This would create some kind of hierarchy of nodekits and its maintainers, which
would make the further development of OpenSceneGraph more flexible, I think.
All the maintainers of the nodekits should get their own svn permissions to
being able to commit to the svn, however only to their own projects.
Maintainers of a category would get responsible to bring all the projects into
one NodeKit-Pack/Category-Pack and make sure, that the pack is compileable and
compatible with current osg version. This will free up Robert, who is spending
maybe his whole time to the project, and will also make the decision about new
features more democratic :)
What I imagine is that when you download osg you get just the basic
functionality and nothing more. Then you decide to have gui functionality,
hence you download the GUI-NodeKit and you get the osgGA, osgWidget, osgText
and other nodekits which are still marked as official OSG GUI nodekits. All
that nodekits/nodekit categories provided on the main webpage are officialy
validated. Projects which are like to became officialy validated, would have to
be investigated by the main maintainer (Robert) and by the submaintainer,
responsible for the nodekit group where the new project like to be included in.
Release of osg 3.0 will be a good point to do so, because the backward
compaitibility has no to be fully supported as it was done during the 2.x
development. And my personal opinion is, that this kind of project development
will make it more flexible and will let evaluate the OpenSceneGraph faster,
which more or less became a game engine rather than a scene graph ;)
Best regards,
art
------------------
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=5006#5006
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ing. Mario Valle
Data Analysis Group | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
