On Saturday 05 April 2003 08:41 am, Chris Leishman wrote: > On Saturday, April 5, 2003, at 04:20 PM, Tod Harter wrote: > <snip> > > > It REALLY seems to me that if you need to pass complex information, > > then an > > object should be passed. In other words I think that while its > > tempting to > > use the Apache::Request object as a way to carry your data around, it > > really > > isn't the best idea for a variety of reasons. Really what should > > happen is > > that each stage in the pipeline should pass along an "AxKit::Request" > > object > > which can contain everything the next stage(s) of the pipeline needs, > > including file handles, DOM tree references, Serialized XML, SAX events > > perhaps, as well as references to the Apache::Request object etc (which > > should be wrapped up tightly so that you never actually call their > > methods, > > just methods on AxKit::Request). > > Actually, this is exactly what the Cache patches I put together does. > The object that's passed along to each stage of the pipeline is > actually a subclass of an "AxKit::Provider". So it's either > AxKit::Provider::File if the data is coming from a file, > AxKit::Provider::Cache if the data is coming from a cache store, or > AxKit::Provider::Scalar if it's coming from memory (eg. the result of a > previous transformation). > > To get rid of the pnotes stuff it would be best to extend the > AxKit::Provider interface to contain some way to get&set metadata > associated with the provider. That way the metadata can be configured > depending on where the data is coming from - eg. a File provider might > set some data about the file type, or a Cache provider can just return > the metadata that was inuse when the cached version was created. > > It would probably also be required to extend the return values from the > processors futher to contain arbitrary metadata. In my cache patches > the processors can now return not just the result code, but a hash > containing a DOM tree and/or a string of data, a ttl and a content > type. Those are specifically looked for and used when creating the > Scalar provider for the next stage - but I don't see why any other > elements returned in the hash couldn't just be thrown into the new > provider as metadata.
Seems like the most efficient way would be to have a contained "metadata object" So the provider just carries a reference to that and each stage can just pass that reference along to the next stage when it builds its output provider, with whatever changes it wants to make along the way. That means very little copying of data around from object to object. As for the object itself its just a hash with get/set methods. > > > This would not only make AxKit more maintainable but it would also make > > migration to Apache 2 MUCH MUCH easier. It would also make it much > > easier to > > create things along the lines of "AxKit B2B" where you want to use > > AxKit > > outside of the Apache environment because now you can reimplement the > > AxKit::Request object and a lot of the rest of AxKit never has to > > change at > > all. > > My thoughts exactly. It just made so much sense to rework it that way > when doing the incr. cache patches. Now the AxKit::Apache object and > pnotes hack is only kept for backwards compatibility with processors > that expect things to be moved around via pnotes or friends. > > Regards, > Chris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Tod Harter Giant Electronic Brain http://www.giantelectronicbrain.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
