Micro kernel use cases? (was: [RT] Micro kernel based Cocoon)

[Bertrand Delacretaz <bd...@apache.org>]

Le 22 mai 05, à 20:24, Daniel Fagerstrom a écrit :

> ...It would require quite a lot of work to give a fair overview of 
> what we have discussed about this in the last three or so years. You 
> find some info in http://wiki.apache.org/cocoon/Blocks...

Would it be possible to come up with a (small) set of "blocks-oriented" 
use cases to re-sync our collective vision of what a micro-kernel 
Cocoon would bring?

I'm thinking of use cases like "start the Cocoon kernel", "load a block 
at startup", locate and download a block after startup", "debug my 
block during development", "use a block service from my own code", etc.

I don't know if the granularity is right, but having a set of use-cases 
(not more than about two A4-pages?)  might make it easier to agree on 
concrete ideas.

-Bertrand

Re: Micro kernel use cases?

[Daniel Fagerstrom <da...@nada.kth.se>]

Ralph Goers wrote:

> Bertrand Delacretaz wrote:
>
>> Le 22 mai 05, à 20:24, Daniel Fagerstrom a écrit :
>>
>>> ...It would require quite a lot of work to give a fair overview of 
>>> what we have discussed about this in the last three or so years. You 
>>> find some info in http://wiki.apache.org/cocoon/Blocks...
>>
>> Would it be possible to come up with a (small) set of 
>> "blocks-oriented" use cases to re-sync our collective vision of what 
>> a micro-kernel Cocoon would bring?
>>
>> I'm thinking of use cases like "start the Cocoon kernel", "load a 
>> block at startup", locate and download a block after startup", "debug 
>> my block during development", "use a block service from my own code", 
>> etc.
>
I have focused on low level mechanisms, like classloader issolation this 
far and havn't done any formal use case analysis. It would certainly be 
usefull to do and it would also be rather independent of if we use OSGi 
or something else. Your proposed usecases seem reasonable. If you start 
a wiki page, I and others can contribute when having thought more about 
it ;)

> 1. Start Cocoon kernel.
> 2. Load Portal Application which causes:
>    2a. Load Portal block dependencies.
>    2b. Load Portal block.
> 3. Configure portal application which causes:
>    3a. Load Internal Portlet block dependencies.
>    3b. Load Internal Portlet blocks.
>    3c. Configure Internal portlets.
>   If this can be made to work along with reloading portlets I would be 
> ecstatic  Hmm. This also makes me wonder if the PortalManagers 
> couldn't be modified to take advantage of this now without modifiying 
> the Cocoon core, at least with respect to portlets.

Whithout knowing the details it seem pretty close to what I have in mind.

/Daniel

Re: Micro kernel use cases?

[Ralph Goers <Ra...@dslextreme.com>]

Bertrand Delacretaz wrote:

> Le 22 mai 05, à 20:24, Daniel Fagerstrom a écrit :
>
>> ...It would require quite a lot of work to give a fair overview of 
>> what we have discussed about this in the last three or so years. You 
>> find some info in http://wiki.apache.org/cocoon/Blocks...
>
>
> Would it be possible to come up with a (small) set of 
> "blocks-oriented" use cases to re-sync our collective vision of what a 
> micro-kernel Cocoon would bring?
>
> I'm thinking of use cases like "start the Cocoon kernel", "load a 
> block at startup", locate and download a block after startup", "debug 
> my block during development", "use a block service from my own code", 
> etc.

1. Start Cocoon kernel.
2. Load Portal Application which causes:
    2a. Load Portal block dependencies.
    2b. Load Portal block.
3. Configure portal application which causes:
    3a. Load Internal Portlet block dependencies.
    3b. Load Internal Portlet blocks.
    3c. Configure Internal portlets.
   
If this can be made to work along with reloading portlets I would be 
ecstatic  Hmm. This also makes me wonder if the PortalManagers couldn't 
be modified to take advantage of this now without modifiying the Cocoon 
core, at least with respect to portlets.


>
> I don't know if the granularity is right, but having a set of 
> use-cases (not more than about two A4-pages?)  might make it easier to 
> agree on concrete ideas.
>
> -Bertrand