On Sunday 07 December 2003 12:44, Mike Chamberlain wrote: > The problem your seeing is a bug/feature of axkit as it currently works.
Aha, OK! Thanks for the response! > In order to setup a pipeline, axkit needs to know what sort of xml it's > looking at, > so it sniffs the content [ first call to provider ], then having built > the pipeline > it reads the content again [ second call ]. OK. But it is not starting from scratch? I mean, by creating a new Apache::AxKit::Provider (or rather the subclass thereof) object? I'm adding data to $self, i.e. this object, so if this object was destroyed, my provider should construct all my other objects again, currently by reading everything from a DB, and so I shouldn't have a problem. > The problem is that the way providers/axkit currently work, it's not an > easy problem > to fix without fundamentally changing the way a few things work. OK. Just an idea that came to my mind, would it make sense to mandate a method to tell AxKit what sort of xml it should be expecting, and just call that instead of asking for the full content? >At the > moment > providers are not cached, so if possible you could just stash the > results away from > the first call to return in the second. Obviously this isn't a great > long term solution, > since if ever anyone optimises axkit to cache providers then > potentially lots of things > could break. Yup... Anyway, since I store stuff in $self, and $self is apparently not destroyed between the calls (?), I could just check if all the needed data have been loaded allready. That's the robust way of doing it anyway, but there are those awful time constraints that I'm sure I'm not the only one who suffers under... :-) BTW, providers are not cached at all...? So, mtime and that stuff is sort of a future-proofing thing...? Or have I missed something...? > Things become really hard when your provider implements get_fh, and the > fh your returning > is a socket. Yeah, I can imagine... > I'm looking at ways to resolve this, but at the moment I've not got any > great solutions. Yup, but it is good to know you're looking at it! :-) Cheers, Kjetil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
