cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Content view separation... are we making a mess? ;-)
Date Tue, 26 Sep 2000 09:50:27 GMT
Scott_Boag@lotus.com wrote:
> 
> > #2 means that you need a way for server side caches to call specific
> > logic to estimate if the cache must be reprocessed or not. XSLT has no
> > notion of this (even if I believe it can be added with no big changes)
> 
> I would very much like to see some examples of what you're thinking.

Ok, the strategy is very simple: under heavy load, most dynamic pages
change less frequently then they are served.

A tunable caching strategy allows dynamic pages to be cached.

Cocoon1 provides this feature using the Changeable interface: if your
producer implements Changeable, the cache will call the hasChanged()
method when the request arrives to estimate if it has to retrigger the
pipeline or send what is already cached in memory.

Since XSP are compiled into Producers, your XSP page can be dynamically
cache by doing

 <xsp:page>
  <mypage>
    <xsp:logic>
      boolean hasChanged(Object context) {
        // put your code here
      }
    </xsp:logic>

    blah blah
  </mypage>
 </xsp:page>

but there are two problems in this approach:

1) the method is *always* called synchronously and must be fast in order
to have a significant impact on performance.

2) XSP 1.0 has no specific semantic for caching and the caching stragegy
is not portable across implementations since it has to connect to Cocoon
internals.

> Can
> you create a small example transform specification with this logic in it?

This nothing related to transformation but only generation. In the XSLT
case, even if all your extentions are ergodic, you are still dependant
on what you have to transform.

So, while for generation you have

 A -> B

so B is ergodic if and only if A is ergodic.

for transformation you have

 A -+-> B
    |
    C

so B is ergodic if and only if, both A and C are ergodic.

You state that the generation case is just like transformations without
input (A is zero)... but this is ridiculous: it's like saying that 

 A -+-> B
    |
   null

is equal to 

 null -+-> B
       |
       C

just because both have a null in their equation.

> I'm still not sure what should be in the syntax in this regard.  Are you
> thinking of something like the HTML meta command that can tell how often
> the update should be done?

That's one of the possibilities that was requested... but the real
ability is to be able to indicate specific logic to extend the caching
strategy with your personal business logic.
 
> > For #3, tell me, how can I honestly go to users and say that they have
> > to use something that is called "extensible stylesheet language for
> > transformations" to create compiled server pages that do not transform
> > anything nor happen to have anything to do with style?
> >
> > Believe it or not, naming IS an issue and a pretty big one.
> 
> I'm not sure what to do about this.  Names are important.  If we could only
> agree on what they mean...

You guys believe that just because both generation and transformation
spit XML content they are the same thing.

The graphical examples from above *clearly* indicate your vision of
dynamic content generation is distorted and clearly
transformation-centric.... while *everyone* on this list agrees that XSP
are a much cleaner solution when it comes to dynamic content generation.
 
> If this is such a factor, why not create XLT, that is a superset of XSLT,
> does not allow xsl:stylesheet, and adds a few things like the cache control
> you're talking about?  It would be a lot better than total redundancy.

I still don't see the need for transformation-centricity.

> > Which leads us to #4: I cannot advocate the use of a technology I cannot
> > influence directly. So the WG must either give us *good* reasons for not
> > accepting our proposals (even name change and WG plitting!!!) or we keep
> > doing our stuff which we are perfectly happy with.
> 
> A general solution needs to address that generality carefully.  I agree, if
> you can not accept this and the limitations that come with it, then you
> probably don't want this solution.  There are a lot of decisions made by
> the WG that I don't agree with, and I wouldn't mind making changes in the
> process.  I still like XSLT.

I *never* said I don't like XSLT: it's cool, it's awesome, it's a
transformation language and it's perfect for that role.

Don't make it brew coffee though.

> And XML probably wouldn't be what it is (for
> better and worse) without the W3C.  Where you find fault, you should also
> give some credit.  I've seen a whole lot of folks say that XSLT should do
> this or do that.... it's the working group's job, as a group of people who
> are very familiar with all the ugly and intricate details, to try and find
> the right balance.  It's actually a pretty thankless job... (to quote James
> Clark directly).

I know and I *never* failed to give you guys respect from your work and
you perfectly know this.

At the same time, we are on the other side of the fence and we see
things that you guys don't see (or don't seem to see... not much
communication happens from the WG out)
 
> It sounds like you are firm on XSP, which I don't mind, I would just prefer
> focus on XSLT, if that were the right thing.  So be it, I just wanted to
> give my perspective.  Thanks for listening.

No problem.

But I'm not going to trade my freedom for a W3C stamp and lots of
corporate chains.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------


Mime
View raw message