Darren New <dne### [at] sanrrcom> wrote:
> Since the owners of POV-Ray have said they're not going to do it anyway, 
> is there a point in answering all these questions?

  The point is that if people stopped thinking only like "I want plugins,
plugins are cool" and started to think how these plugins should work,
what their interface (in C++ terms) should be, where exactly should the
core code call these plugins and what should the core code offer these
plugins, how the core code should implement the things to offer to the
plugins and so on, they could perhaps start realizing that "adding
support for plugins" is not just a question of laziness nor even of
portability (even though portability is an important issue as well).
  Just to present an example: How exactly should the core code be modified
and which kinds of interfaces should it offer to the plugins so that the
plugins could create new primitives, new patterns, new texture properties,
and even completely new features unrelated to anything else already
existing in the core?

> Or is your point that 
> there's no possible answer to these questions, in spite of there being 
> plenty of highly portable systems that do allow such things? Just 
> curious, really. :-)

  Usually dll plugins in windows programs perform one single isolated task
which is very well defined. Let's take for example a Winamp DSP effect
plugin: The concept is rather simple. There's probably a function or two
which winamp calls and which the dll implements. These functions get a
well-defined raw sample which the function can modify and then just 
return to the caller. And that's it.
  How about a photoshop filter? There's probably one function in
the dll which photoshop calls which is of the kind "here is the
raw image, do whatever you want with it". Then the function in question
does something to it and returns. And that's it.

  Now, would you care to explain how this basically simple plugin
ideology could be embedded into POV-Ray? Where exactly should POV-Ray
call what? Should there perhaps be a dll function call for each one of
the hundreds or thousands of features POV-Ray performs so that the
dll plugin could affect it? For example, should POV-Ray make a dll function
call for each ray it shoots, for each color it computes, for each
media sample interval it calculates, for each radiosity sample it
computes, for each photon ray, for each parsed token, for each
primitive created, for each transformation parsed... The list could
go forever. There would be literally thousands of functions being
called, cluttering and adding overhead. I think you get the idea.

  So once again: How exactly should the plugin engine be implemented?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message