xml-axkit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sergeant <m...@sergeant.org>
Subject Re: AxKit2 Strawman
Date Wed, 19 May 2004 22:44:45 GMT
On 19 May 2004, at 10:01, Tom Schindl wrote:

>> Providers, we lower the barrier to AxKit's potential adoption... 
>> people can generate the content any way that they know and are 
>> fast/comfortable with, and can still have AxKit's built-in 
>> style/media-choosing capabilities and other features while 
>> transforming that content for delivery. Seems like a big "win" to me.
> It is certainly and that's why I think AxKit2 *has to be* an mp2 
> filter.

I agree. However this is the current situation (almost - assuming your 
input is perl and you substitute mp1 for mp2).

I can see two issues here that I'd like to address in the migration to 
AxKit 2:

1) AxKit able to transform output from non-perl apache modules (e.g. 

2) AxKit is too complex for some people to get working.

This is almost two sides of the same coin - we can do #1 quite easily 
if we sacrifice #2 (or at least maintain the status quo with #2). We 
also might be able to do #1 without sacrificing #2, but there's an 
affect on the code.

I personally think #2 is more significant than #1 because of the 
number-of-users factor. How many users need to filter content from 
another module with AxKit (excluding perl stuff and things that can 
work as a Provider)?  Practically zero. We're very unlikely to be 
persuading PHP shops to install both PHP and AxKit (and thus mod_perl) 
just to get XML transformation in the output chain. We can postulate 
about how cool this might be, but we also need to be realistic about 
whether there's actually a call for this.

I also think that it's probably time to just start thinking about 
getting *something* working with mp2. Even if it's not the perfect 
input/output filter system we ultimately want. We can build on it from 


View raw message