Now, I have read your entire RT, and I must agree with Stefano (he is the FS sniffer around here ;o) ). +1 on the FS Award. Don't feel humiliated, most people have problems with FS and SoC (Separation of Concerns).
You find that Cocoon sitemaps are useful for other types of piped processing. Fine. IMHO, it would be more suitable to bring the Sitemap to other "projects", than bring other "projects" to Cocoon. It is probably easier to "convince" Stefano and others (me for instance) to "expose" an official sitemap API, which can be incorporated into other projects, the types you mention for instance. However, I like the notion that there are "typing information" (of DTD/Schema) for block's inputs and outputs, so at least the configuration tools (not the sitemap in runtime, that's just waste of CPU resources) can validate the "pluggability" between blocks. The exact mechanism for this is a lot harder, because it needs to be simple and non-intrusive. Also, until there are blocks and some more solid configuration tools, this is less important than, for instance, flows, and can wait. Niclas On Monday 10 February 2003 23:49, Hochsteger Andreas /INFO-MA wrote: > Hi Neeme! > > > -----Ursprüngliche Nachricht----- > > Von: Neeme Praks [mailto:[EMAIL PROTECTED]] > > Gesendet: Montag, 10. Februar 2003 13:24 > > An: [EMAIL PROTECTED] > > Cc: Andreas Hochsteger; Andreas Hochsteger > > Betreff: Re: [PROPOSAL] Cocoon Science Fiction > > > > > > > > I agree with Stefano on his point that if this kind of > > machinery is to > > be done, then it should not be done inside cocoon. > > I don't think that it's so much different about what Cocoon does today. > But see my comments on Stefano's mail for this explanation. > > > Instead, it would be much more sensible to do this on a more general > > level: write an Avalon based server for dealing with any data > > type where > > it would be possible to plug in Cocoon "block" as well. > > Then you could have a block interface like this: > > serialized data -> block -> serialized data > > And Cocoon could be just one of the many implementations for this. > > This is an interesting solution. > I just feel a bit strange to have so many similarities which will result in > duplicated code in your suggested Avalon server and Cocoon. > But it's definitely worth to investigate it as possible solution, if we can > reuse much of Cocoon. > > > Rgds, > > Neeme > > > > Stefano Mazzocchi wrote: > > [..snip...] > > Bye, > Andreas > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
