In article <d5ckfr$2s5$1@chho.imagico.de>, chr### [at] gmxde says...
> Apart from that what you wrote does not mention what you think would be 
> possible by dynamically linking the POV-Ray backend with a different app 
> that is not possible to do via stdin and stdout of the official version. 
> 
Well. The one advantage having something closer to a library than a 
stdin/stdout system has is being able to easily drop it into another 
application. You don't need to know as much about how and why it works to 
use a library. At worst you might need a wrapper for the language you 
plan to use. Stdin and Stdout aren't as universal as they should be, if 
they where people wouldn't have developed DCOM, Corba or other 
implementations for a different method of linking stuff together.

Of course, most of the problem wasn't just having POVRay sitting 
someplace else chugging away in its own window, so much as the lack of 
anyone trying to find out what all of the interfaces where good for and 
my almost nonexistent skill in C. Yeah, its possible to create a wrapper, 
etc. for 'other' languages, but if you don't comprehend the way they work 
in C you are out of luck with the rest too. Decoupling the frontend and 
backend means the backend 'could' be more like a library than a full 
application, which makes the interface between them less complex, doesn't 
require complicated plugins to sit as intermediaries, etc. Sort of the 
computer equivalent of interchangeable parts + fewer moving ones that 
might break. But that may just be how clueless I am about how any of it 
works in the first place. ;)

> BTW i just announced a program in tools.general that demonstrates how 
> you can integrate POV-Ray into another program using these means.
> 
Hmm. Will take a look.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message