xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hardy <vha...@eng.sun.com>
Subject Re: commit and interpreter API changes
Date Mon, 05 Feb 2001 17:03:01 GMT
Thierry,

Thierry Kormann wrote:

> 1. I create an InterpreterPool (or choose the default one).
> 2. I choose a GraphicsNodeRenderContext (or use the default one).
> 3. I have my user agent (or use a predefined one)
> -> I can create as many BridgeContext as I want for as many documents as I want
> 
> So, that's why I prefer the InterpreterPool not be linked to a particular
> document (it's just a pool or a factory in my opinion).
> 
> I think that we could have the same behavior as before if in the
> BridgeEventSupport or whatever, you ask, the first time you find a script, an
> Interpreter and keep a reference on this one for future script elements.
> 
> I think it should be the responsability of the BridgeEventSupport to cache/reuse
> the same Interpreter if needed (not a build-in feature of the InterpreterPool).
> 
> At last, to let the Interpreter goes to GC, that will be possible when the
> BridgeEventSupport will release its listeners and other resources on the
> document.
> 
> Any comment?

I agree with the concern that you have to make the API simple for the
Batik 
user. However, I am not  too familiar with the InterpreterPool, but I 
would think that you need the notion of document somewhere, if only to 
find the handlers of specific events and make sure that the
'myECMAScript'
function in doc1 does not shadow the 'myECMAScript' function in doc2...

How would that be done if the InterpreterPool is not linked to a
particular document?

V.
> Thierry.
> 
> --
> Thierry Kormann
> email: Thierry.Kormann@sophia.inria.fr  http://www.inria.fr/koala/tkormann/
> Koala/Dyade/Bull @ INRIA - Sophia Antipolis
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org

Mime
View raw message