 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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-asg com
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
|
|
| |
| |
|
|
|
|
| |
|
|
