> I was talking about write, not read. If you have a partial cache > architecture you have to write cache on every stage in the pipeline. > > Say you have 5 stages, and your first two get cached. You still are > writing to cache on 3 stages. If 3 cache writes are more expensive than > the pipeline it's not worth it, especially if the first two stages are > fairly lightweight (which they often seem to be).
Yep, that is a good point... I'll have to think about that one. Maybe some form of "lazy caching" would mitigate that. > > OK, but that's one "point" in the pipeline that you cache, rather than > arbitrary. > Yes, but the point was that its not necessarily the LAST stage in the pipeline, which is the only point you're looking at. > I'm not sure I entirely grok how that would work, unless you're talking > about some form of agregated pipeline. In which case I think agregated > pipelines can be broken down under my view of things as several separate > pipelines that end up joining as one. > OK, I'm not quite sure what you mean by an "agregated pipeline" either, we'd probably have to go over it in detail, there may be points I'm missing. > Yep. And I think Cocoon2 might have too much focus on being smarter than > the programmer in this case, whereas in fact we need to let the programmer > choose the strategy (if we go that route). > I'm all for DUMB systems to tell you the truth. My philosophy is that computers are about as smart as your average flatworm, and should be relegated to grunt work only. I > > Me either :-) That's why I started on AxKitB2B, to try out some of these > ideas. ;o). Well, we think alike then. When I first looked at Cocoon I wondered why they made that distinction too. > > > In a lot of cases I see things that it seems like to me where some fairly > > modest generalizations would be beneficial, though to be honest I haven't > > had a chance to review every section of the code, so this may be a case > > where it just looks that way from the 900 foot view. > > At the moment the AxKit code is a mess. There's some terrible > inconsistencies in there. The Provider stuff is hackish, and the Language > modules need better separation between what's a "transformer" and what's a > renderer. But there's some smart moves in there - like how XSP is just a > transformer with no stylesheet, and the internals of XSP, which I still > think are pure genius (modest about it too, I am ;-). lol. I guess I'm not sure what the distinction wants to be between "transforming" and "rendering". All processing of data is transformation from input to output, so how really would any particular stage be different from another? In the most generalized sense what we're really hashing out here is how to optimize the architecture of pipelined processing. In thinking about it I've seriously considered the concept of constructing a perl "Pipeline.pm" that essentially deals with all the various issues. > > Seriously, if you want to inflict some good design, take a look at > AxKitB2B, and we'll back-port some of the better stuff into AxKit later. ok > > > Steve Willer will tell you that I regularly underestimate the depth and > complexity required to implement sophisticated web apps ;-) > I've been told I make some really complex ones as well, hehe. To be honest I still don't have the depth of experience building one in XSP/XSLT that I feel confident I know the best general approach. One of the reasons I hesitate to be too insistent on a particular architechnology. > > As an aside: http://www.chatspace.com/products/webboard/versions/unix.cfm > > (I wrote it, well, some of it. It's mod_perl, and should integrate nicely) > Cool. I'll take a look at it. > > you can't use them together because each one has a completely different > > data storage model, a completely different authorization and > > authentication mechanism, different styling mechanisms, etc. By the time > > you rewrite them all to work together with the same user base even you > > might as well have started from scratch. > > Sure, I agree completely. > > That's what we do. However if you go SOURCE -> XSLT -> XSP then an mtime > isn't enough, because your stylesheet may have changed too generating > different code (that's a bug at the moment - patches welcome :-) Well, caching at each step does address this. Maybe a compromise approach would be to have the last processor in the chain check the times on all the files in the chain. I guess that would basically mean analyzing the various files for stylesheet PIs and making a list of what depends on what, but that could be done just once per chain offline (basically create a "dependency map" that you can check). In theory that could even be extended to request attributes. That would get rid of the "writing to the cache at every step" issue. > > Yep. We can cache SAX events using Storable on the filesystem, or using a > database. The nice thing about SAX is it's completely linear, so it's just > a sequence of cache objects. > > Please join in on [EMAIL PROTECTED] (send > mailto:[EMAIL PROTECTED]) and share ideas there about > this sort of thing. I've already got an architecture written that takes a > "sitemap" and does a SAX processing chain based on that, and can return it > via HTTP [1], but there's still a lot more coding needs to be done, and a > lot of influence over design can be had. OK, will do. I love programming challenges ;o). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
