I did miss something.  sorry.

Nigel Stewart wrote:
> 
> Okay, here are the major advantages:
> 
> *  Totally portable file-names, time/date, integrity checking.

This would be great.

> *  Easier management for 3rd party modules.
> *  Ability to take a fully-functional pov source snap-shot.
> *  Simpler installation, less registry/variable dependence. (*)

I'm tempted to start a flame war but won't.  Lets just say that I
strongly agree with any move to reduce the use (direct or indirect) of
registry files Regedit on the few occasions when I do boot my computer
into Windows.  Of course, .rc files can be a pain on Linux too.

> The filename resolution issue is not yet resolved.
> At the moment, POV simply looks in the current
> directory and treats each tar file as an entry in
> the library path.  This might not be the best policy -
> I'm still thinking about it...  The intention is to support
> this transparently - it should make no difference
> if you are rendering from a real filesystem or a
> tar filesystem.

OK.  If you tar a directory tree, do the subdirectory levels get
searched.  If so, are they treated as subdirs?  Here's what I mean...

You want to make a tar of a whole tree you've made and nicely organized
that looks like this:

/include
/include/incs
/include/pots
/include/maps
/include/maps/hot
/include/maps/cold
/include/ttfs
/include/df3s

Would a file in /include/maps/hot be treated as being in a subdirectory
of a subdirectory or would it just get treated as a file with /'s in
it's name?  I'd advocate the later.  It may sound nuts to have subdirs
in a library tar like that, but I'm sure someone will try it.

BTW, how does tar (gpl'd I think) get along with POV license-wise?

> Compression is under consideration - Pov already
> includes the zlib library, so gzip or JAR support would
> not introduce much new code.  My feeling is that
> a case needs to be made for the parse-time expense
> vs. space savings.  Also, it might be cleaner to support
> compressed pov/inc as preferrable to compressing an
> entire archive.

There was an earlier thred about making a binary file format of parsed
scenes.  It would be kinda cool if that goes of to put parsed .inc files
into the tar.  That way, you kill a whole pile of parse time for anyone
who includes a lot of stuff from these.

Three more potential problems...

1)  Documentation:  If all the includes come as one big tar (or
whatever) file, then people won't be able to peruse them the way they
can now so a whole new pile of documentation will have to made available
stating what's in each include file.  (Big PITA when it comes to stuff
like shapes.inc)  It may require some sort of standardization of the
include files.  (I'd be willing to volunteer for that).  Personally, I
don't use the standard includes much anymore, but they were an
increadable help when I was learning back on POV 2.whateveritwas.  The
loss of the ability to see their guts would be a big blow to new users.

2)  Home-brews:  There'd have to be some sort of utility (hardwired into
POV or released separately) so that people could make their own
modules.  And of course, it would have to work on several platforms.

3)  Conflicts:  Suppose you define Big_red_texture in one .inc file and
then redefine it in another one later.  You then put both of them in the
tar.  Depending on how you do file resolution this could confuse either
pov or the user (either pov will freak, or else 50% of the time the user
will not get what they wanted because it took Big_red_texture from the
other .inc)

Well, now that I've said all that...I like the idea afterall.  If you
want someone else to test a patch on Linux, let me know.  

Cheers!
-- 
Carl Bartels, Department of Chemsitry, Mcgill University, to reply to
me,
just kill a and 5 from the email name, Montreal, QC, cAnAdA

Post a reply to this message