As <[EMAIL PROTECTED]> wrote:
> Different environments, and different users, do want
> different cache management policies.
I think it's clear from just a couple of days
discussion here that this is quite true!
Personally, I'd like to work on getting xsltc
integrated into more of the javax.xml.transform
package first - both matching the
Templates/Transformer metaphor to translets better and
making sure that various ancillary methods (output
properties, parameters) also work a'la JAXP standards.
The org.apache.qetest.trax package *should* be only
dependent on JAXP itself, so most tests there should
run on xsltc as well as Xalan (I still need to
double-check I didn't leave old forced-xalan
properties in there).
Also, having xsltc support SAXSource/SAXResult and
DOMSource/DOMResult will be important, although that,
esp. DOM, may take some more integration work.
As others have mentioned, so many bits of caching are
application or environment specific that it's really
hard to implement in our JAXP and under layer. My
preference for now would be to implement a couple of
sample applications on top of JAXP that implement
caching of Templates(translets) in simple situations -
then users can grab this code and have caching as they
like, but we don't have to complicate (and test, and
add maintenance costs) the inner workings of xsltc and
xalan with caching functionality.
If people really do want to work on translet caching
now inside of xsltc's implementation, then we should
see what can be done inside of the JAXP API's
themselves without modifications. One idea is to add
functionality to xsltc's
TemplatesImpl/TransformerFactoryImpl (or whatever
class) to do simple cache mapping from .java -> .class
to automatically recompile if needed. Nothing fancy,
just a one-to-one mapping and file timestamps. This
should be off by default, and can be turned on by an
appropriate TransformerFactory.setAttribute(attr,
value) call - see
org.apache.xalan.processor.TransformerFactoryImpl for
the two attributes Xalan currently supports. By
default it can use '.' or user.dir as the location for
.class files; or it can have another setAttribute that
specifies this location (oh, and maybe the source
location). I'm really thinking this logic should be
more in Templates and not in Transformers.
Does any of that make sense?
- Shane
=====
<eof aka="mailto:[EMAIL PROTECTED]";
humor="'A Midsummer Night's Dream' - pick your quote" />
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
