You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axkit-dev@xml.apache.org by Kip Hampton <kh...@totalcinema.com> on 2004/05/18 16:41:32 UTC
AxKit2 Strawman
Howdy,
Find attached a first cut (incomplete in many ways) for what I think an
AxKit2 base might look like. The ideas I was seeking to prove/disprove are:
* AxKit can be implemented a modperl2 Filter
* AxKit1's internal pipeline can be replaced by a direct interface to
MP2's new pipeline.
* Given #2, AxKit plugins and language modules are really just modperl2
filters that are added dynamically by the main AxKit2 Filter.
Thoughts, ideas, comments, flames, etc. are most welcome.
-kip
Re: AxKit2 Strawman
Posted by Chris Prather <ch...@prather.org>.
On Tuesday 18 May 2004 12:41 pm, Tom Schindl wrote:
> Hi Kip,
>
> I admit I like the idea of using MP2 filters. I haven't really looked at
> your code but what do you think we would gain when using filters for the
> pipeline model? How does this go together with the concept of changing
> the pipeline model?
>
> My personal view of AxKit2 looks like the following:
> * AxKit2 is a input/output filter handler
> * AxKit2-Input-Filter-Engine (=AxKit1 Plugins) is *one* Input-Filter
> * AxKit2-Output-Filter-Engine (=AxKit1 Processors) is *one*
> Output-Filter
> * AxKit2-Output-Transformers(=AxAddOutputTransformer) adds
> Output-Filters
>
> I don't see any big advantage to design the axkit-pipeline as
> input/output filters. Another big advantage when AxKit2 is a mp2-filter
> is that the response handler could be any PerlResponse-handler which
> would at least contradict somehow the importance of XSP, doesn't it?
Actually I don't see that at all. Rather I think it puts XSP where it belongs,
one of many choices in generating XML for the pipleine. With AxKit as an MP2
filter it can take XML from (potentially) any response handler and feed it
through the transformation pipeline and spit it out. With all the
AxKitty-goodness we have now.
By making AxKit-Language moduels into MP2 filters, it means that you can just
use AxKit::Language::XPathScript when that's all you really need and you
don't want the stylechoosers and whatnot. You can setup a 'static' mini-axkit
pipeline. And you can feed it all into any output filter that will work on
the end of a MP2 filter chain.
But what I find MP2 really brings to the table on this is the fact that the
pipeline need not be entirely Perl base. Meaning you can generate XML with
mod_php, transform it with AxKit::Language::Sablot and output it with
mod_gzip. Tell me that isn't a nice thought when you're given a legacy PHP
website and told that you now need to target not only HTML, but PDF and RSS
as well.
-Chris
Re: AxKit2 Strawman
Posted by Tom Schindl <to...@bestsolution.at>.
Matt Sergeant wrote:
[...]
>
> 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
> there.
And so do I. It's really time to get something working.
>
> Matt.
>
>
--
b e s t s o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl leiter softwareentwicklung mobile ++43 664 3145958
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck fax ++43 512 935833
http://www.bestsolution.at phone ++43 512 935834
Re: AxKit2 Strawman
Posted by Matt Sergeant <ma...@sergeant.org>.
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.
php)
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
there.
Matt.
Re: AxKit2 Strawman
Posted by Tom Schindl <to...@gmx.at>.
Kip Hampton wrote:
> Tom Schindl wrote:
>
>> Hi Kip,
>>
>> I admit I like the idea of using MP2 filters. I haven't really looked
>> at your code but what do you think we would gain when using filters
>> for the pipeline model? How does this go together with the concept of
>> changing the pipeline model?
>
>
> It doesn't really effect it all that much. What changes is that AxKit
> would use an interface MP2's pipeline, rather than by creating its own
> pipeline internally (which would seem redundant given that MP2 gives us
> one for free).
>
And that's exactly what I'm afraid of because your stuck with the
Apache2/MP2 Filter-Pipeline-Model although maybe in future you'll want
to implement things not working with this approach.
Nevertheless how do you think that the concept of incremental caching
could be implemented using your Apache-Filter concept?
[...]
>
>
> The primary benefit isn't for AxKit users, but for others with simpler
> setups that might want XSLT or XPathScript transformations but for whom
> a full-blown AxKit would be overkill. Think of it as a sort of a
> middle-step to bring in new users.
>
I see your point. But couldn't it be the other way round that e.g. the
Language-Modules like Ax2::L::XSLT are surrounded by a Ax2::F::XSLT so
the module could be used into the "old" setup where you have AxKit2 act
as one output filter with its own pipeline-model and once as a Filter.
>> Another big advantage when AxKit2 is a mp2-filter is that the response
>> handler could be any PerlResponse-handler which would at least
>> contradict somehow the importance of XSP, doesn't it?
>
>
> Some people Like XSP, others would rather be shaved, smothered in
> pancake syrup and tied to an anthill rather that use it or any other *SP
> technology. By not forcing people to learn XSP, or custom application
And so do I. Tracking down problems with XSP is a pain nobody likes
debugging but debugging XSP failures is really a pain.
> 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.
Tom
>
> -kip
>
>
>
Re: AxKit2 Strawman
Posted by Kip Hampton <kh...@totalcinema.com>.
Tom Schindl wrote:
> Hi Kip,
>
> I admit I like the idea of using MP2 filters. I haven't really looked at
> your code but what do you think we would gain when using filters for the
> pipeline model? How does this go together with the concept of changing
> the pipeline model?
It doesn't really effect it all that much. What changes is that AxKit
would use an interface MP2's pipeline, rather than by creating its own
pipeline internally (which would seem redundant given that MP2 gives us
one for free).
>
> My personal view of AxKit2 looks like the following:
> * AxKit2 is a input/output filter handler
> * AxKit2-Input-Filter-Engine (=AxKit1 Plugins) is *one* Input-Filter
> * AxKit2-Output-Filter-Engine (=AxKit1 Processors) is *one*
> Output-Filter
> * AxKit2-Output-Transformers(=AxAddOutputTransformer) adds
> Output-Filters
All of these can be encapsulated in a single filter (that "wedges" in
the other filters-- first the Plugins, then the Languages, the the
OutputTransformers). Why have 3 when 1 works just as well?
>
> I don't see any big advantage to design the axkit-pipeline as
> input/output filters.
The primary benefit isn't for AxKit users, but for others with simpler
setups that might want XSLT or XPathScript transformations but for whom
a full-blown AxKit would be overkill. Think of it as a sort of a
middle-step to bring in new users.
> Another big advantage when AxKit2 is a mp2-filter
> is that the response handler could be any PerlResponse-handler which
> would at least contradict somehow the importance of XSP, doesn't it?
Some people Like XSP, others would rather be shaved, smothered in
pancake syrup and tied to an anthill rather that use it or any other *SP
technology. By not forcing people to learn XSP, or custom application
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.
-kip
Re: AxKit2 Strawman
Posted by Tom Schindl <to...@gmx.at>.
Hi Kip,
I admit I like the idea of using MP2 filters. I haven't really looked at
your code but what do you think we would gain when using filters for the
pipeline model? How does this go together with the concept of changing
the pipeline model?
My personal view of AxKit2 looks like the following:
* AxKit2 is a input/output filter handler
* AxKit2-Input-Filter-Engine (=AxKit1 Plugins) is *one* Input-Filter
* AxKit2-Output-Filter-Engine (=AxKit1 Processors) is *one*
Output-Filter
* AxKit2-Output-Transformers(=AxAddOutputTransformer) adds
Output-Filters
I don't see any big advantage to design the axkit-pipeline as
input/output filters. Another big advantage when AxKit2 is a mp2-filter
is that the response handler could be any PerlResponse-handler which
would at least contradict somehow the importance of XSP, doesn't it?
Tom
Kip Hampton wrote:
> Howdy,
>
> Find attached a first cut (incomplete in many ways) for what I think an
> AxKit2 base might look like. The ideas I was seeking to prove/disprove are:
>
> * AxKit can be implemented a modperl2 Filter
> * AxKit1's internal pipeline can be replaced by a direct interface to
> MP2's new pipeline.
> * Given #2, AxKit plugins and language modules are really just modperl2
> filters that are added dynamically by the main AxKit2 Filter.
>
> Thoughts, ideas, comments, flames, etc. are most welcome.
>
> -kip