> Yes and no. > > The intent is to use the same patterns that inspired the creation of > Phoenix (which are included in the original Avalon design that Pier, > Federico and I invented), but *not* to clone Phoenix! > > This is because the 'service' concept that can be provided by a > collection of logic components is very different from the 'internal web > service' concept that a cocoon block should provide.
Oh, I see what you're saying. > This different perspective, in fact, suggests different factorization of > blocks from the ones you outlined above, which are, in fact, > logic-oriented instead of 'concern-oriented'. > > Implementation-wise, I'm pretty sure we might end up "using" parts of > Phoenix directly (or patch it to make it abstract enough to handle our > needs as well), but at a totally different level (app-level rather than > core-level) and driven by different needs and concerns. I'm not saying that Phoenix blocks should be used to implement "Cocoon services", they are not meant for that. Cocoon could use Phoenix very much how James uses it (mailets), or if an app. server would be build using Phoenix (ejb deployment). Building on top of Phoenix doesn't mean that Cocoon cannot have it's own packaging scheme, I think it should because it addresses different concerns (web related). ..... > In case you don't want the installer to go around shopping for this, This is an example of what a Phoenix service could do for Cocoon. Going around and shop for blocks is not a web related service but a deployment service thus easily implemented using a Phoenix block. Things like: XML database, search engine, object store, servlet&JSP engines, or Cocoon container are well suited to be implemented as Phoenix blocks. > you > provide a single 'deployment descriptor' which indicates the entire > collection of URI where things are located on the web and the installer > goes there, grabs everything it needs and installs. But that's just one > xml file, not another package (it reduces the need for multipackaging > and makes it easier for us to publish blocks and create > web-service-driven repositories for behavior-based block shopping). ..... > > This things are currently implemented in Phoenix, but in kernel space. I > > agree that these features should be implemented in application space, > > having a Cocoon specific implementation but service oriented. > > 'web service' oriented, I would say. > > My personal idea of a 'web service' is not just a way to have CORBA > implemented in XML over HTTP, but a way to provide *all* the information > one needs to use that web service. That requires not only logic, but > also all the resources (images, stylesheets, static pages, help > documents, etc..) that are required by the *user* of that service > (either a human directly or another web service) ...... > Of course, I totally agree on the concept, but I don't think that > Phoenix is capable of providing solution for all our needs since Avalon > Blocks are very different from Cocoon Blocks (even if they aim use the > same design patterns). Of course they would be different, and they should be. All I'm saying is that Cocoon blocks would be deployed into a service (not web service) oriented framework like Phoenix is, where Cocoon container would be just another Phoenix service. Please have a look at how James uses Phoenix, or how HP app. server uses their core service framework (very similar to Phoenix). Source code is available at: http://www.bluestone.com/SaISAPI.dll/SaServletEngine.class/products/downloads.jsp. Mircea --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
