xml-axkit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Schindl <tomAtLi...@gmx.at>
Subject Re: AxKit2 Strawman
Date Wed, 19 May 2004 09:01:01 GMT
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.


> -kip

View raw message