cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: The road to Cocoon 2.1
Date Sun, 16 Mar 2003 15:18:45 GMT

Stefano Mazzocchi wrote, On 16/03/2003 10.29:
> Jeff Turner wrote:
> 
>> On Sat, Mar 15, 2003 at 06:09:44PM -0500, Tim Myers wrote:
>>
>>> I usually just lurk...
>>>
>>>
>>>>     - write a block-like modular system in the build for
>>>>         - flow
>>>>         - xsp
>>>>         - actions (yet to be agreed upon)
>>>>         - instrumentation (yet to be understood how)
>>>
>>> Can't this wait until a 2.1 point release?  It is a major change but 
>>> doesn't
>>> involve interface changes from what i gather of the most recent 
>>> discussion on the sitemap (actions and flow).  XSP (from a packaging 
>>> POV) is nothing more than a group of components.  I don't see that 
>>> factoring these things out is
>>> a prerequisite to a 2.1 beta or even final.
>>
>> I agree.
> 
> 
> Oh, that's no problem for me.
> 
> Carsten, you propsed the move: what's your feeling about this?

One note from me:

These "refactorings" have their importance, but I agree that they are 
not a necessary prerequisite to an alpha release, but they are to a 
final release.

For flow and xsp, if anyone wants to try it, just give a notice ahead of 
time and do it; the build is just a copy of the blocks one with a change 
in the directory name.

For Actions, I don't think we really object in having them pluggable (on 
the basis that if I can use them, it's ok), but it would also be nice to 
do it in a more comprehensive manner, discussing how to make distro 
customization more pluggable. I have a couple of ideas, but we'll have 
to see it together.

Then we have instrumentation... which relies on a package that IIUC is 
not released. Well, it's darn cool, but it also introduces a dependency 
someone might not want. ATM I'll just leave it, because it does produce 
interesting data for performance measurement, and I'd also like to see 
it as part of our daily performance tests.

I have here also an idea of how to deal with this, a sort of poor man's 
concern weaving... ok it's simple, just add every "concern" as comments, 
and have a preprocessor "weave" them in.

For example:

  //@instrument(what to do)
  //@log(what to log)
  //@assert(what to check for)

  /*@instrument

    more instrumentation code

  */

In this way we can insert commands *without* needing to compile them if 
we don't want to. We can also use different instrumentors or loggers 
with the short form, as long as they understand the abstract semantics.

The problem here is that this needs a filtered copy, which many have 
loved to hate... but if we can enhance the compiler to use our version 
of the filesystem that does this on the fly, no copy is needed.

I still have to work on this, but I'm starting to like it :-)



Ok, back to the mail.

I'd add to the above modules all the environments. Are you all ok if I 
move them too (last time you "all" were it seems)?

Ciao :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message