OK, as long as the caching is better then that's OK I guess... I did
some work on mediawiki a few months ago when they were having trouble
keeping up with scaling and really solidified my previous opinion
that scaling well is all about static caching. I mean, putting off
anything dynamic to be as late in the pipeline and as small as
possible. In the case of wikipedia, their code is just a nasty
nightmare spaghetti monster... that I don't have the time to untangle
right now.
But with my own stuff on semacode.org I do want to add user logins
and interactive features eventually. On the other hand, I don't want
to use AxKit for everything, at least for the foreseeable future. For
example I've adopted Sympa as my mailing list manager. It's really
good, too. I'd like to build bridges between these different
platforms and I'm still trying to figure out how that's going to work
(some kind of common auth framework presumably is needed). I don't
want to have to use "the AxKit MLM" (since there isn't one now
anyway...) but I do want to be able to integrate everything seamlessly.
--simon
On Aug 6, 2006, at 10:11 AM, Matt Sergeant wrote:
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.
--
http://simonwoodside.com
