In article <em35ps$uuv$1@chho.imagico.de>, chr### [at] gmxde says...
> Patrick Elliott wrote:
> >
> > Well, its not "quite" the same. ActiveX has advantages that static 
> > methods don't.
> 
> Well - since you don't give any concrete example here this is difficult
 
> to comment on.  Note however that apart from license issues any such 
> non-portable approach would be
> 
> > [...]
> > 
> > The reason this is a licensing issue is that it technically allows you
 
> > to provide an partially disabled version, 
> 
> No, see 2.2-f of the source license:
> 
> "If that directive is not present, the Modified Version must work in the
 
> same way as the Licensed Version."
> 
> Any unofficial version should by default work exactly like the official o
ne.
> 
> Now what you described is just an extension of the quality switch in 
> POV-Ray.  Nothing prevents you from implementing this *inside POV-Ray* 
> (if it is turned off by default).  You can also pre-process a scene with
 
> a separate program to disable certain parts.   But having an external 
> hook to switch POV-Ray into an incompatible, crippled mode would violate
 
> the above part of the license as well as section 1.6:
> 
> "[...] Modification to these APIs or other officially supported 
> communication mechanisms (or the addition of any new code or feature) 
> for the purpose of avoidance (or to assist others to avoid) the intent 
> of this or any other POV license is expressly prohibited."
> 
> Once central purpose of the POV-Ray source license is to avoid 
> modifications of POV-Ray to impose limits to the users concerning their
 
> use of POV-Ray.
> 
Hmm. Well, its a bit of  gray line in this case. The purpose of 
implementing such a limit is to "hopefully" automatically apply limits 
that prevent parse times or render times that would exceed any 
reasonable time limit. If you are looking at a game that incorporates 
this as a rendering system, but you don't *absolutely* need "real time", 
which isn't practical, as in, 30 seconds to "at most" a minute thirty. 
Allowing things that in combination are "certain" to produce longer 
times is not a great idea. Mind you, one could simply leave it entirely 
open and let the scene maker deal with how to decrease the render and 
parse times.

In principle the sandbox is just another ini. Its one "specific" to the 
this implementation as a inlined rendering engine, but not "required" by 
the program in any other context. Ironically, your argument seems to 
imply that adding it as something that works in "all" contexts is more 
acceptable, since it becomes a "rendering setting", than when limited to 
one specific use?

Ok, how about this. Allow the sandbox to act like that, but instead make 
the ActiveX command have two forms:

pov.render ("myscene.ini") - Functions just like the "existing" 
interface.

or

pov.render ("myscene.ini", False) - Functions as above.
pov.render ("myscene.ini", True) - Uses the sandbox limits.

Its just extending the capabilities then, even in the interface, since 
the default behavior is "indistinguishable" from the normal one, right?

****

In principle, one option going to the issue with ActiveX vs. other 
methods, you can do with ActiveX one thing you "can't" with the existing 
method, even if it is platform independent. With ActiveX I could have 
open (presuming I didn't mind the lag and memory issues):

1. Regular copy, rendering a big file.
2. ActiveX instance that is generating an image with low render 
settings.
3. ActiveX instance that is generating a longer render time version of 
2, along with other queued images, with higher quality settings.

and, I don't have the "keep single instance because the program running 
both version 2 and 3 can't tell who they hell they are talking to. I 
understand that "is" an issue with the current system, which is why 
Moray requires you run it only in "single instance" version. There is no 
way for the OS, the program making the calls, etc. to "know" which one 
it is dealing with. ActiveX has one big advantage in that each instance 
is uniquely identified in the OS. And, just to be clear, while this may 
not "technically" be cross platform, there are implementations of things 
like Mono that "are" available under Linux and support the same sort of 
unique identification and instancing systems. While it may have been 
true in the past that there was no "better" option, this isn't exactly 
true now.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message