On Fri, 30 Nov 2001, Stefano Mazzocchi wrote: > giacomo wrote: > > > > In software terminology, an accumulator is normally called a "store", > > > "archive", "cabinet", "safe" and so on with terms that give you an idea > > > of "something" that allows you to place information that will > > > persistently remain there. > > > > A Sink as opposed to a Source. But seems to be mutually exclusive as what > > Jeremy is proposing with his WritableSource (which IMO isn't a good name > > as well as SinkSource). > > I like the term "Resource" better since it's direction agnostic.
Ok. > > > So, does this mean we need a "Store"-behaving component in the cocoon > > > pipelines? > > > > > > No, such a store-behaving component would not be distinguishable from > > > another transformer. > > > > I'm not so sure. Today we feed the Serializer with an OutputStream where > > it can "store" its output onto (even if this is outward from a requestors > > point of view). What about using the same architecture for a > > StoringPipeline where the last component (accumulator for now) will be > > given a Sink to store the Output it produces. > > Yes, I agree the storing behavior could be shaped as a serializer but we > need some data to come out (see my last post on this thread). > > > > Thus, a "store" is behaviorally equivalent to a "transformer". > > > > Well, in term of web applications (and CMS is more a web application that > > a publishing system) I'd like to see the inward step separated from the > > outward one. We need to be able to perform some logic in between inward > > and outward processing. > > I don't think you can directly connect the inward > > pipe to the outward pipe without giving an Action a chance to act on the > > results of the inward pipe. > > Oh, absolutely, see my writable cocoon: proposal in my last post. After thinking about it another while I don't think my statements above are still valid. The logic I wanted to be processed in between of the inward and outward pipeline can easily be done with transformers. BTW: Does anybody know what the performance impact of NullTransformers are? I thought of what Berin told us concerning the Handler stuff in Axis. NullTransformer as I want to tell are XPipes which only forward SAX events to it successors and might be triggered at lets say the StartDocument event to inspect the environment (Request, Session, etc) to acomplish some logic and are done afterwards. If chaining lets say 10 such Transformers together will be a impact on performance we can take an "unchaining" functionallity into acccount where a transformer can tell that it wants to leave the chain of pipeline components. BTW2: With the approach having the Request as a pipeline will standardize the way how requests should be handled (with pipeline components) This way XSP-Transformers could be realized which are then able to trigger a redirect as many users still think they need it (we know that we cannot use Redirect functionallity in a outward pipeline) > > > As Jeremy pointed out, XUpdate is a choice. I must tell you that I don't > > > like XUpdate that much, but I admit it's a choice. > > > > Please share your oppinions on XUpdate with us. <snipped Stefano's oppinion about XUpdate/> Thanks for sharing your oppinion. > > > Or we could use CVS, file systems, relational BLOBs, defragment the > > > document into LDAP nodes, FTP, POST it somewhere else, email it to your > > > mom, fax it to your brother, print it on a piece of paper for your > > > favorite human slave to subsequently crawl... > > > > > > ... up to you. > > > > Crys for an abstraction like Prowler!? > > Maybe, or maybe not. > > I've been in favor of the adoption of Prowler as an Apache subproject, Uh, again. I hope this time the PMC will be stronger than last time I tried to do it :( > but I've been really discouradged by the amount of people that use it > (virtually zero, AFAIK). Falko and others from the Infozone Group even > drove all the way from Germany to talk about this with me, but in all > honesty, their view of a CMS is too much of a blackbox to me. > > And as I wrote before, we need a toolkit more than a black box. I'd like > to give Cocoon the underlying functionality of becoming the frontend for > your own CMS, rather than plugging Prowler in, or creating a > CMS-behaving Avalon component. Sounds reasonable. > I'm afraid, to be honest, that no matter how good the CMS is, I'd need > something more, but not in terms of storage facility (which is > relatively easy), but in terms of workflow management (something that > Prowler currently lacks) and stuff like that. Workflow capability is IMHO a absolute need for a CMS (as well as revision control). > What would I gain in having Prowler once I have a writeable dbxml: > protocol? Different Resources (OODBMS, RDBMS). > > > Jeremy named it "WritableSource" (which is admittedly an ossimoron). > > > > [havn't found 'ossimoron' in my dict(?)] > > I meant "Oxymoron" (sorry for my horrible english spelling skills) is a > rethoric figure used in litterature: > it could be explained as "semantically strident" or "semantically > conflicting". It's normally used in litterature to trigger deeper > reasoning in the careful reader, but normally makes the reading > experience harder, even if it conveys much more information. In ermetic > poetry, it's the rule rather than the exception. > > Here, I was being recursively semantically strident with my irony :) > > [unfortunately, giving you the semantic context afterwords ruined the > joke entirely] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
