cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [FYI] www.ormaz.it usecase
Date Tue, 15 Apr 2003 09:42:11 GMT
on 4/15/03 9:42 AM Jakob Praher wrote:

>> b) flowscript rocks the planet. it will rock even more combined with
>>hot-deployable avalon components.
>>
> 
> 
> been thinking about this for a long time ... 
> It would be interesting, what we need in order to have hot-pluggable
> avalon components - afaik it would not be that hard, the hardest problem
> ist the current EMCs way of getting component information (from the
> monolothic .xconf). 

hopefully fortress will help us with this.

> What are the most difficult points here - I guess the component reload
> order and dependencies among different components.
> 
> I thought about differntiation between the core (sitemap processor, etc)
> and custom components, that could be more easily reloaded and thus more
> dynamic.
> 
> 
> For instance for blocks I would keep things simple ( kiss you know ),
> all we need is something like:
> 
> interface BlockDeployer{ 
> 	
> 	void insert( Block aBlock ) throws DeployerException;
> 	void update( Block aBlock ) throws DeployerException;
> 	void remove( Block aBlock ) throws DeployerExcpetion; 
> 
> }
> 
> I think we could learn much from the Kexts (MacOS Kernel Extensions) or
> Linux Kernel Modules ( insmod, rmmod, ... ).
> 
> Sorry for being so evocative again. (but dreaming of cocoon blocks or
> plugins for a long time now ... )
> 
> Whats your opinion, state of mind on this?

start small and grow and see where this leads us. As soon as we have a
cocoon 2.1 final I'll start playing with this (time and travelling
permitting, of course)

>> d) flow + inputmodules + redirection from flow totally substitute the
>>need for actions in the sitemap. The elegance of the resulting solution
>>is not even close to be action-based equivalent.
> 
> 
> sounds interesting. I will try to update my expermiental projects using
> flow.
> 
> ....
> 
> 
>> f) cocoon needs an xml repository as an avalon component accessible
>>from the flow! the use of protocols is simply not enough for the kind of
>>data manipulation required in seriously roundtripping webapps that have
>>to mix, match and change stored xml content. This doesn't need to be an
>>xml database, it could be a virtual file system on top of a blob-capable
>>DB or a CVS view.
>>
> 
> wondering about slide and jsr 170 - there are interesting things going
> on there recently (day.com has contributed a ri for jsr 170).
> 
> I am evaluating slide for a cms system now. But have not had time to
> play with slide + cocoon.

JSR 170 is definately the way to go. This is another item in my
light-year-long todo list :-)


-- 
Stefano.



Mime
View raw message