On Tuesday 11 June 2002 8:49 pm, Ken Neighbors wrote:
> Matt Sergeant writes:
> > First of all, do you know that both XSP and LibXSLT will read gzipped
> > files already? I haven't tried it, but libxml2 has built in support for
> > gunzipping on the fly.
>
> No, I didn't know that.  I will look into it.
>
> My approach was that AxKit was generating an "Internal Server Error"
> whenever I accessed "sample.xml" or "sample.xml.gz" because
> "sample.xml.gz" was the only file on the system.  I saw in the error
> log that the parser was complaining:
>   [AxKit] [Error] xmlParse returned error: 4, Start tag expected, '<' not
> found so, assuming the parser could not handle gzipped files, I patched
> Provider::File to decompress the file before the parser got to it.
> But I will try to find out how to get the parser to handle the
> compressed input directly.

That might be because to get the start tag I pass in the first 200 bytes or so 
to the parser, but I do this as a string, and libxml2 doesn't support 
gunzipping for a string. I guess you need to go the provider route instead.

> > Secondly, this is best implemented as an alternate provider. See the
> > AxContentProvider and AxStyleProvider options. Just subclass the File
> > provider and implement the get_fh and get_strref methods.
>
> That sounds ok except for one possible drawback (correct me if I'm
> wrong): multiple providers that provide "one extra feature" without
> the ability to use features from different providers at the same time
> (because only one provider is used to process a request).  For
> example, I see that a new FileWrite.pm was submitted in CVS.  How
> would a user be able to select FileWrite capability in conjunction
> with GzFile capability?  (Maybe this isn't a good example.)

Well the FileWrite is experimental. We may at some point move to writable 
providers, and so it's been checked in to play with that idea. You're talking 
about a generic problem with OO, and I don't think anyone has ever solved it 
fully (there are Interfaces and Mixins as alternate ways to "fix" this but 
they all have problems in the scenario you describe), so we'll just have to 
suck it and see. I still think despite this problem that an alternate 
provider is the best way to solve your problem.

Matt.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to