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