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: [RT] Flow as a block
Date Fri, 14 Mar 2003 14:01:50 GMT

Stefano Mazzocchi wrote, On 14/03/2003 14.49:
> Nicola Ken Barozzi wrote:
> 
...

>>  - people don't like/use actions and would like to see support for it 
>> removed
>>
>> ? I regard actions on par with all other Cocoon Sitemap Components. 
> 
> I, for one, don't.

We know, we know ;-P

>> They are part of our basic sitemap contract IMHO, I would keep them 
>> in, also because it does not bloat Cocoon or add additional dependencies.
> 
> But I would like to be able to build cocoon without them and prevent 
> people with the ability to use them to solve their problems. Just like 
> Carsten wants to do with the flow or XSP.

That's not the reason IIUC.
Flow adds new dependencies to Cocoon as jars, actions do not. What is 
the technical reason why actions have to be able to be removed?

If you don't want to use them, don't. Since people will be able to 
compile with the support in, they will do so, and you will not prevent 
them to use actions (nor ATM it's desireable).

Is this a soft deprecation of actions? ;-)

>>  - people dont' like/use the avalon instrumentation and would like to 
>> see support for it removed
>>
>> This is tricky, Instrumentation is an "aspect", and thus cannot 
>> cleanly be separated ala OOP. How do we do this?!?
> 
> Yes, tricky. I wonder how useful instrumentation is given that java 1.4 
> has pretty damn serious remote debugging interfaces.

And damn slow I may say. Instrumentation can instead be used in 
production to monitor the app. A different domain AFAIK.

>> All the above can be done, but a question remains: how do we 
>> physically manage them?
>>
>> That is, I propose the we simply compile them as the blocks are 
>> compiled now, with explicit dependencied and needed jars, the 
>> compilation exclustions, and samples...
>>
>> Shall e have a .src/modules/** hierarchy?
>>
>> ./src/modules/flow
>> ./src/modules/servlet-environment
>> ./src/modules/cli-environment
>> ./src/modules/bean-environment
>> ./src/modules/instrumentation
>> ./src/deprecated  <-- move it here for consistency
>> ...
> 
> 
> it doesn't matter where we put it, but how we do it.
> 
> removing actions and the flow is just a matter of moving classes and 
> patching the treeprocess configurations. xconftool can be used for that.
> 
> removing XSP and the compiled language components can be done by moving 
> them and patching the configurations with the xconftool
> 
> I don't know about the servlet dependency.


Easy: put the code as outlined above, and see if it compiles (as said on 
the other thread). As done with the blocks.

> I have no idea on the instrumentation since we might require to 
> 'aspectize' our code and this means java pre-processing and I don't 
> think I like this approach. What about virtual AOP thru proxies? but 
> that should be something done by the classloader, I think...hmmm.

Yes, but not easy ATM. Instead of thinking in theory, where is 
instrumentation used? (the lines of code)
Where should it be used?

Then we can see if it can be done with runtime code decoration.

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


Mime
View raw message