(if this is a duplicate, i apologize)

Hey, guys, thanks for responding to the post so well,
I was just tossing the idea into the ring, of something
I had already done....


Ron Parker wrote:

>
> Neat idea, but I have questions.  First, how would it
> handle it if you did your first example above, and
> somfile.pov #included a local .inc file?  Would it
> implicitly put http://someserver/ at the beginning of
> the include path while processing remote files, or
> would all #includes have to be explicit?  Also, what
> happens when someotherfile.inc defines a macro?  At

Yes, something like an HTML page has.....  the images/files
it includes are either stated absolutely (http://.../.../filename) or
relatively (filename).   In other words, the first (main) document
loaded provides the DocumentBase, and all others can be
considered relative to it, like a directory of web pages.

As far as macros go, simple caching of the files locally would
do it.  Most bowsers run this way, also.... they cache the file
in a local directory, then open a file pointer to the local file.
Then they use a URL name---->cache name mapping scheme
for consistency....

>
> Why is this even necessary?  Are network file systems
> like NFS or SMB too cumbersome?  If you're going to
> have to run an HTTP server on the master machine
> anyway, why not run a more lightweight custom protocol
> better suited to providing the needed information?  You
> might even consider a protocol that can just send the
> entire preparsed frame and global settings to each client
> rather than duplicating the parsing effort.

Ohh... no,  I'm sorry, I wasn't clear.
When you say "master machine" it sounds like a business domain
or some institutional LAN or organization or something.  This is more
of an aid to the common man, posting his pov files to an ISP,
or something like that.

Not all PovRay users are in an environment where they can
use domain-networked PC's, or NFS...  This idea is more
of a "poor man's" solution, where the users might have
no privileges at all, nor do they have the knowledge or
ability to run a network service.   That's what I mean by
"simple" networking scheme. Simple, simple, simple... ;-)

No networking smarts required of the PovRay artist....
Lots of people know how to post data to
ISP servers; not many know how to export or mount NFS volumes.
Also, very, very few commercial sites will allow their customers
to run a server of their own, in this case, for
distributing POV information.

Just consider the number of web sites in the world today, compared
to institutional LANs.  The possibilities of -large- scale distribution would
be enormous.

(Plus, I've programmed for many years, and fear describing anything
technical to the customer   ;-)

Besides, in the original post, I suggested using the existing libwww
library from W3.org to provide the Web client capability, to avoid
reinventing the wheel, and taking advantages of its many features,
such as the caching mentioned above.

I really think the price/performance ratio of this idea is pretty good...
Not much programming or program complexity required, but
a -LOT- of additional power.


If this were to be a "standard" patch, then one wrapper function
in the PovRay source for all readfile and writefile fopen()'s would
be nice, to help make the hook. -OR- allow this to be done in a
plugin module, if that architecture is in the future of PovRay.

BTW, I've been a PovRay user for years, think it's about the best
shared software in the world, and worship the ground the PovRay guys
walk on.

Ok, I'm done typing....    Thanks again and see u later.

.


Bob

Post a reply to this message