One thing I would like to add to any Wish List for
new PovRay additions would be the ability of the
parser to refer to resources by URL, in addition to
file names.  This would enormously simplify the problem
of transferring resources for distributed raytracing.
For example, if povray could have a command-line
switch like:

+Ihttp://someserver/somfile.pov

and the parser could handle:

#include "http://server/someotherfile.pov"

or

gif "http://imageserver/image.gif"


...then a client application would never have to explicitly
copy any data at all.

The libwww library from W3.org adds this functionality
simply&easily, and is almost as multi-platform as POV itself.
This would also aid in the addition of XML and UML
capabilities in the future.
I have tested a simple patch, and would share the info
with anyone who would like to know how.



Bob
rja### [at] lincom-asgcom

Post a reply to this message

On Thu, 28 Jan 1999 10:45:10 -0600, Bob Jamison <rja### [at] lincom-asgcom> wrote:
>One thing I would like to add to any Wish List for
>new PovRay additions would be the ability of the
>parser to refer to resources by URL, in addition to
>file names.  This would enormously simplify the problem
>of transferring resources for distributed raytracing.
>For example, if povray could have a command-line
>switch like:
>
>+Ihttp://someserver/somfile.pov
>
>and the parser could handle:
>
>#include "http://server/someotherfile.pov"
>
>or
>
>gif "http://imageserver/image.gif"
>
>
>...then a client application would never have to explicitly
>copy any data at all.

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
present, every invocation of a macro results in the
file in which it is defined being reopened, fseek'd 
to just after the #macro, and the macro reparsed with
the new symbol table.  I think POV needs to make
temporary local copies of the required include files,
or at least the macro definitions, in this case.
Finally, the way #while is handled might be problematic,
as the #end causes it to seek back to the #while and
reparse until the #while ends up false.  I'm pretty
sure http doesn't allow for random access like this.

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.

Post a reply to this message

In article <36b0a016.0@news.povray.org> , par### [at] my-dejanewscom (Ron 
Parker) wrote:

> 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.

I agree to a certain extend, however, a limitation to the host file
specification part (e.g.
http://www.netspace.org/users/dwb/url-guide.html#file ) of it might be
useful to get more abstract optional file and path names on systems with
different directory/folder separators. And the URL style would also
eliminate the leadind space volume name on Macs and otehr potential problems
like this.


    Thorsten

Post a reply to this message

On Thu, 28 Jan 1999 13:32:46 -0600, Thorsten Froehlich 
	<fro### [at] charliecnsiitedu> wrote:
>I agree to a certain extend, however, a limitation to the host file
>specification part (e.g.
>http://www.netspace.org/users/dwb/url-guide.html#file ) of it might be
>useful to get more abstract optional file and path names on systems with
>different directory/folder separators. And the URL style would also
>eliminate the leadind space volume name on Macs and otehr potential problems
>like this.

I can agree with that, and I would suggest supporting such URLs on #fopen
as well.

Post a reply to this message

On Thu, 28 Jan 1999 13:32:46 -0600, "Thorsten Froehlich"
<fro### [at] charliecnsiitedu> wrote:

>In article <36b0a016.0@news.povray.org> , par### [at] my-dejanewscom (Ron 
>Parker) wrote:
>
>> 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.
>

It might come in handy for things such as IMP, where people will be
rendering scene files that are stored on a machine accessible by the
internet. It might also be nice to be able to output the images to a
given URL instead of just to a local file.

Later,

Glen Berry

Email:    7no### [at] ezwvcom
(remove the "7" to reply via personal email)

Website:  http://www.ezwv.com/~mclilith/index.html

Post a reply to this message

In article <36b3d4ab.15220878@news.povray.org> , 7no### [at] ezwvcom (Glen Berry)
wrote:

> It might come in handy for things such as IMP, where people will be
> rendering scene files that are stored on a machine accessible by the
> internet. It might also be nice to be able to output the images to a
> given URL instead of just to a local file.

However, for a platform independent project it is very hard (impossible?) to get
network access in any portable way.  If you support Sockets and Streams you will
most likely support most platforms, but not all, that is for sure.
And as Ron said, NFS (there is surely a client on every platform for it) or
other network file systems do a much better job than any proprietary interface,
even it is based on http, ftp or whatever else.


      Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> In article <36b3d4ab.15220878@news.povray.org> , 7no### [at] ezwvcom (Glen Berry)
> wrote:
>
> > It might come in handy for things such as IMP, where people will be
> > rendering scene files that are stored on a machine accessible by the
> > internet. It might also be nice to be able to output the images to a
> > given URL instead of just to a local file.
>
> However, for a platform independent project it is very hard (impossible?) to get
> network access in any portable way.  If you support Sockets and Streams you will
> most likely support most platforms, but not all, that is for sure.
> And as Ron said, NFS (there is surely a client on every platform for it) or
> other network file systems do a much better job than any proprietary interface,
> even it is based on http, ftp or whatever else.
>
>       Thorsten

And my $.02 worth:

As much as they sound fun, as Tech Director for the IMP I've been working on various
distributed things, and I must say that the URL thing scares me.

Now, I think that there is a place for all that, but not in POV-Ray itself. Do one
thing and do it well.

Post a reply to this message

In article <36B3FD5B.5800FF44@geocities.com> , "Jon A. Cruz" 
<jon### [at] geocitiescom> wrote:

> Now, I think that there is a place for all that, but not in POV-Ray itself. Do
> one thing and do it well.

Right!


    Thorsten

Post a reply to this message

On Sun, 31 Jan 1999 00:21:02 -0600, "Thorsten Froehlich"
<fro### [at] charliecnsiitedu> wrote:

>In article <36b3d4ab.15220878@news.povray.org> , 7no### [at] ezwvcom (Glen Berry)
>wrote:
>
>> It might come in handy for things such as IMP, where people will be
>> rendering scene files that are stored on a machine accessible by the
>> internet. It might also be nice to be able to output the images to a
>> given URL instead of just to a local file.
>
>However, for a platform independent project it is very hard (impossible?) to get
>network access in any portable way.  If you support Sockets and Streams you will
>most likely support most platforms, but not all, that is for sure.
>And as Ron said, NFS (there is surely a client on every platform for it) or
>other network file systems do a much better job than any proprietary interface,
>even it is based on http, ftp or whatever else.

Well, actually, I've never been able to find a free Windows NFS
client, which is why I mentioned SMB.

Post a reply to this message

On Sat, 30 Jan 1999 22:51:07 -0800, "Jon A. Cruz"
<jon### [at] geocitiescom> wrote:


>As much as they sound fun, as Tech Director for the IMP I've been working on various
>distributed things, and I must say that the URL thing scares me.
>
>Now, I think that there is a place for all that, but not in POV-Ray itself. Do one
>thing and do it well.

Agreed.  If you want to use URLs, write a Perl wrapper that gets the
required files and puts the results and calls POV in between.  The
Perl people have already worked out all the hard bits.

Post a reply to this message

In article <36b89a00.90826283@news.povray.org> , par### [at] mailfwicom (Ronald L.
Parker) wrote:

> Well, actually, I've never been able to find a free Windows NFS

Yes, that is a problem, PC-NFS is a bit expensive :-)   On the other hand I am
surprised tha no shareware developer has implemented it yet (isn't RFC1813 the
standard document for it?).


    Thorsten

Post a reply to this message

In article <36b4a965.0@news.povray.org> , "Thorsten Froehlich" 
<fro### [at] charliecnsiitedu> wrote:

> In article <36b89a00.90826283@news.povray.org> , par### [at] mailfwicom (Ronald
L.
> Parker) wrote:
>
>> Well, actually, I've never been able to find a free Windows NFS
>
>(isn't RFC1813 the> standard document for it?).

Ups, it is RFC1094...

    Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> 
> In article <36b3d4ab.15220878@news.povray.org> , 7no### [at] ezwvcom (Glen Berry)
> wrote:
> 
> > It might come in handy for things such as IMP, where people will be
> > rendering scene files that are stored on a machine accessible by the
> > internet. It might also be nice to be able to output the images to a
> > given URL instead of just to a local file.
> 
> However, for a platform independent project it is very hard (impossible?) to get
> network access in any portable way.  If you support Sockets and Streams you will
> most likely support most platforms, but not all, that is for sure.
> And as Ron said, NFS (there is surely a client on every platform for it) or
> other network file systems do a much better job than any proprietary interface,
> even it is based on http, ftp or whatever else.
> 
>       Thorsten

Oh, all these guys having all permissions of the world.

I just try heavily to imagine making my SysOp opening their NFS-Volumes
to the whole world.
There's got to be a more graceful way to commit suicide.

Axel

Post a reply to this message

> Oh, all these guys having all permissions of the world.
> 
> I just try heavily to imagine making my SysOp opening their NFS-Volumes
> to the whole world.
> There's got to be a more graceful way to commit suicide.

hey, don't tell them I ran POV on their server, please don't ;-)

//Spider

Post a reply to this message

In article <36B3FD5B.5800FF44@geocities.com>, "Jon A. Cruz"
<jon### [at] geocitiescom> wrote:
>sound fun, as Tech Director for the IMP I've been working on various
>distributed things, and I must say that the URL thing scares me.
>
>Now, I think that there is a place for all that, but not in POV-Ray
itself. Do one
>thing and do it well.

Yes, I think that something like this ought really be implemented in the
operating system itself.

Jerry

Post a reply to this message

On Wed, 03 Feb 1999 07:44:12 -0800, Jerry Stratton <new### [at] hoboescom> wrote:
>In article <36B3FD5B.5800FF44@geocities.com>, "Jon A. Cruz"
><jon### [at] geocitiescom> wrote:
>>sound fun, as Tech Director for the IMP I've been working on various
>>distributed things, and I must say that the URL thing scares me.
>>
>>Now, I think that there is a place for all that, but not in POV-Ray
>itself. Do one
>>thing and do it well.
>
>Yes, I think that something like this ought really be implemented in the
>operating system itself.

Yeah, maybe we can get Microsoft to integrate a web browser... no, wait.

Post a reply to this message

In article <36b87cc9.0@news.povray.org>, par### [at] my-dejanewscom wrote:
>On Wed, 03 Feb 1999 07:44:12 -0800, Jerry Stratton <new### [at] hoboescom> wrote:
>>Yes, I think that something like this ought really be implemented in the
>>operating system itself.
>
>Yeah, maybe we can get Microsoft to integrate a web browser... no, wait.

Does Windows '98 allow the use of URLs as if they were files? If I were
using POV-Ray for Windows '98, could I type

#include "http://www.hoboes.com/html/NetLife/POV/Basics/distances.inc"

and have it work?

That would be almost enough to make me switch platforms.

Jerry
http://www.hoboes.com/jerry/

Post a reply to this message

Jerry Stratton wrote:

> >Yeah, maybe we can get Microsoft to integrate a web browser... no, wait.
> 
> Does Windows '98 allow the use of URLs as if they were files? If I were
> using POV-Ray for Windows '98, could I type
> 
> #include "http://www.hoboes.com/html/NetLife/POV/Basics/distances.inc"
> 
> and have it work?
> 
> That would be almost enough to make me switch platforms.
> 
> Jerry
> http://www.hoboes.com/jerry/

Just tried it and know it does not work. It just issues a
warning that the include file could not be found. Might
be able to tie it in with stdout but that is beyond my
abilities.

-- 
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

(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