Sylvain Wallez wrote: [snip] > BTW, I know quite well CM/CS for having used it a lot in Cocoon and my > projects, but not much Phoenix. It seems to me (and the current > discussions enforce this feeling) there's a lot of redundancy both in > concepts and code between Service/Block and Component > interface/implementation. Moreover, looking at the "what-is-a-block" > page, many of the given examples are what we have as components in Cocoon. > > From what I can, see, a block can provide several services (but AFAICS, > most of them provide only one), whereas a component implements only one > role. Could you enlighten me on this or point me to relevant resources > (other than the web site) ?
Sylvain: In the blocks we (OSM) have developed the number of services provided by a block is typically 2 or more. One service enabling administrative actions between peer-blocks and another service providing normal service provisioning. In one case we have a block with about 7 distinct services. The block is basically mediating requests based on identity of the invoking principal. Our implementations use Block for highly granular components (PKI Manager, Time Service, DPML Engine, Collaboration Framework, Notification Server etc.) whereas the implementation make extensive use of ComponentManager (and ServiceManager) in the structure and management of fine grain components (request interceptors, ORBs, Domain Managers, etc). From that perspective the Block/Component abstractions map together quite elegantly. Cheers, Steve. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
