> -----Ursprüngliche Nachricht----- > Von: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > Gesendet: Montag, 10. Februar 2003 09:45 > An: [EMAIL PROTECTED] > Betreff: Re: [PROPOSAL] Cocoon Science Fiction > > > First of all, let me give you my compliments for a well > thought-out and > written RT.
Thank you very much, I did the best I could, to let it look this way! > Second, I will try to reply in a more short form ;-) , so > please do add > things that I left out. > > - blocks > > blocks will/should be reusable pipelines, in a way similar to what > you envision. I fully agree on this. > - data formats > > This was discussed already when Cocoon was being designed, and > the result is that the sitemap does not check for consisency > of what it is given. This "feature" has never really been a > problem IMHO, so I'd be reluctant to introduce this concept > strongly in the sitemap. A simple validation-transformer in > the right places should suffice. In todays Cocoon I'd be with you, but this proposal is about how Cocoon could look like with version 3 or 4. So here are the reasons, why I think it makes sense: First, you have to deal with pipelines, which don't only produce but also consume data (i.e. get data from the outside). It's really easy to guarantee, that your pipeline components only get the data they are compatible with, as long as you generate it inside the pipeline. If you want to have reusable pipelines which consume data, you have to make sure, that you provide strict contracts between the internals of the pipeline and the externals (usage). Second, the data formats implicitely carry the mime type which is needed by the response. Third, this way it is possible to provide meta data in a standardized way, which can be easily integrated with something like RDF and OWL to facilitate the long awaited semantic web. > - binary data > > There you are :-) > Using Cocoon for binary data transformation is easier than many > may think. Change our pipeline implementation to pipe the > result of a reader one to another, and and it's done. (sort of ;-) > > I have been investigating such a system with Morphos. > - description: > http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons-s andbox/morphos/src/java/org/apache/commons/morpho> s/package.html?rev=HEAD&content-type=text/html > - code: > http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/morphos/ > > I would like to move the effort here, if others agree. > It would go in the scratchpad, > <hint> or in a brand-new "sandbox" </hint> I didn't know Morphus before, but I think it's quite similar. Morphos could be a good start. > - branches > > This has been proposed too and strongly IIRC rejected by > some as FS (flexibility syndrome). This is true for publishing, > a lot less in the flexible transformation engine you envision. > I'd keep this last in the list ;-) I know the problems, which can arise therefrom. In my first attempt they were not mentioned at all. But I think some discussion on more flexibility is not bad. > - protocol indipendence > > We have already, as you say, an environment. What you propose is > to use the same Cocooc instance as a back-end to multiple > simultaneous protocol frontends (mail, http, etc). > Cocoon is a transformation system, so it should not really itself > bother about how to get the data, ie it's not a server. > Would it be a compelling use-case to use a single Cocoon instance > with multiple protocols? Not sure, I don't have the need now... Cocoon does not neccessarily have to deal with this issue, as I pointed out in "8.2 Protocol Mapping". Would Web Services (which can be invoked by different transport protocols) be a sufficient use-case? > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- Bye, Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
