On 6-Aug-06, at 3:28 AM, S. Woodside wrote:
But what you're talking about seems like a major divergence. That's cool, because I can't wait to see how it's all going to turn out. I'm sure it will be interesting. But will it be a solution that I'll want to use?
I hope so. :-)
It seems like you're more abandoning the use of caching as a valuable tool for scalability for example ...
No, that's not quite right. I'm abandoning AxKit's crazy efforts it goes to to try and ensure the cache is used in the right places. Instead you control the cache. Think of it as a pipeline you can inject the cache into - if you want it - and where you want it.
Scalability should be much better with AxKit2. I haven't done any real comparisons yet, but I see no reason that it shouldn't be much improved. There's so much less baggage with AxKit2.
also it looks like I'll have to write perl code to do anything (true?)
If you want to do anything out of the ordinary yes - but you can already use the demo XSLT plugin if all you want to do is XSLT and everything then is setup in axkit.conf.
The thing was - if you wanted to do stuff out of the ordinary with AxKit1 it was a really difficult mix of providers, plugins, and so on. My aim is to make that simpler, plus provide some very cool tools for building applications (maybe a hook to Catalyst or Jifty or something else entirely new).
Anyway, my main interest is in continuing to explore the use of XSLT pipeline/trees. I'd rather avoid writing procedural code (perl or whatever). Is there something else that I should switch to? Will AxKit1 be maintained?
AxKit1 will probably have one more release. There's no reason there shouldn't be an AxKit1 maintainence track, but new development won't happen there.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
