From: Chris B
> if it's successful, it could grow
> quite large and could change quite frequently.

a Version Control System like CVS or Subversion as seen in most colaborative
open-source projects is the correct way to handle it.

> how would you know whether you want to bother with the new additions
> if we don't list them with graphics to illustrate what you'd be getting.

should be nice to be handled by a script, which would see if there is a
sample image available and, if not, would render a small sample on-the-fly
and cache it.  Hey, finally broadband users would get to feel like in the
90's 56K modems! ;)

> My view is that developing a deep multi-level
> taxonomy would turn out to be something of a maintenance overhead, but that
> grouping it all into just one archive would make it cumbersome and messy.

yes, indeed.  some mid-level agreed upon standard would be required.

> My preference would be for a small number of areas of interest with a main
directory for each,

BTW, Ben Chambers take on this one below is also worth a look.

> Most of the contributors to the discussion so far seem more in favour of a
> loose collection of include files where you could download one file at a
> time or a selection of files chosen from a list or through a search.

more of the same way of doing pov things and not unlike most web
collections, rather than standard povray includes.  But hosted at
povray.org itself! :)

From: Ben Chambers
> As for directories / categories / whatever you want to call them, I'd
> keep them extremely abstract and general.

you're suggesting just the hierarchy you layout below?  While i agree it
would be very useful, it's only as part of a top-level hierarchy, much like
to the one described by Chris B, focused on few highlevel areas of interest,
each one branched like yours... perhaps i'm thinking too much in terms of OO
software programming, i dunno...

- Shapes
--Solid (CSG-able)
--Non-solid (Non-CSG-able)

this is good.

- Functions
-- Isosurface

hmm, i believe Isosurfaces (already defined by a function, possibly included
from here) should be under Shapes/Solids.

> This system isn't meant to be browsed by hand; you'd search through it
> via the server to find what you need.

A plain directory with many include files identified only by a prefix ID is
nice when it's on a server machine with searching capability.  But imagine
such a collection in your own machine, with no advanced search and possibly
naming conflicts...

> It would be especially useful if POV-Ray
> accepted URIs to files, and you wouldn't have to download them locally
> to check them out... but that could open a whole new can of worms :)

yes, like when the server's down or people begin putting URIs to external
sites that go out of business... nothing like locality, or at least the
illusion of it. :)

From: John VanSickle
> The objects section should be divided at least into semi-primitive
> objects, which do simple-but-common CSGs

you mean, like "clippers" -- objects that clip others in differences or
clipped_by?

yeah, we coult get an abstract, utilities section...


From: Charles C
> Some people might find
> it easier to replace the whole library directory on their computer than look
> to see if they've got the latest of each component.

those are the broadband non-programmer guys who don't know the benefits of a
Version Control System, in which you just issue an update command and it
automagically downloads diffs from the repository and patches them in your
local copy.  And it even generated nightly builds for those wanting a
single download.

> I've checked now, and the limit for POV-Ray is 25 library_paths that you can
> add to the main POVRAY.INI.

hmm, i begin to feel a need for Makefiles... :P

perhaps only include in POVRAY.INI the main branches and leave specifics to
the command-line?

> might have a dozen related
> files, each with a dozen or more macros within them.

it seems we're seeking for a one object per file standard.

> will one "system" or "project" still have to
> be broken up & spread out in the library according to its components?

you mean textures, shapes and the like?  I believe that's desirable.

Post a reply to this message