Re: lynx-dev stuff like converters, filters (was Re: info pages)

[brian j. pardy]

On Wed, 27 Jan 1999, Klaus Weide wrote:
> On Wed, 27 Jan 1999, brian j. pardy wrote:
> > On Wed, 27 Jan 1999, Klaus Weide wrote:
> > > On Wed, 27 Jan 1999, brian j. pardy wrote:
> > > 
> > > > > The whole HTStream mechanism in lynx is already a way to "plug in
> > > > > filters", but they have to be written in C and be compiled in.
> > > > 
> > > > Hmm.  This isn't a project for 2.8.2, and probably not even for 2.9, but
> > > > is there any way that an interface with some sort of dynamically 
> > > > loadable module could be hacked in there?  That could be an area to
> > > > eventually plug-in Javascript if that ever happens, and who knows what
> > > > else.
> > > 
> > > What I was referring to was filters for converting one sort of text
> > > (as just a stream of bytes) into another, before Lynx does much with
> > > it.  You seem to be thinking about something that would have to happen
> > > at a much later stage.
> > 
> > Oh, I parsed you wrong.  I wasn't sure where HTStream was called.
> 
> It's not just one function getting called somewhere, it's a way of thinking...
> 
> See <http://www.w3.org/Library/User/Architecture/Streams.html>
> and <http://www.w3.org/Library/User/Start.html>
> for intro - ignore the details, most don't apply to Lynx.

Ahhhh.  Well that's not what I was thinking of at all. :)

> > Something could possibly even be done there -- is this where .Z/.gz/.bz2
> > files are internally decompressed?
> 
> Kinda sorta (all the stuff in HTFile.c is from within a stram method),
> but actually they do get _externally_ decompressed, except for .gz with
> --with-zlib, and then only from a local file (not really a streamin filter).
> 
> > It would be nice to be able to specify
> > what does the decompression outside of the code, to better support new
> > compression techniques w/o having to hardcode them.
> 
> Maybe it would be nicer if content-encodings were not hardcoded, but
> more configurable like MIME types.  OTOH inflation of the number of
> compression methods is nothing to be wished for.

Yes, a mime.types style configuration was what I was thinking of, I
think someone asked about that a few months ago.  I'm sure there were
valid reasons not to do so.

> > I tend to go on a link-following spree and never return back to the
> > original document that got me off on the tangent.
> 
> Glad I could give you some now starting points then.  :)

Hey, these'll teach me something, it's perfect :)

> > > I've actually been thinking about duplicating the Apache API in lynx,
> > > so that Lynx could load apache modules. :)  But not seriously.
> > > I mean, except for hack value I don't think there is the slightest
> > > bit of good reason for binary modules in Lynx.
> > 
> > *pondering a perl-scriptable lynx-session*  
> 
> I was thinking only of the retrieval side, not the side facing the
> user.  But one's probably as unrealistic as the other, and I don't
> know which would be more useless...

I don't really know enough about Apache (I can compile it and hack up
a basic server config, but I don't do anything with it) to know which
would be (well, I guess I can't say "useful") interesting...

> > Hmmmm.
> 
> Of course there are already ways to completely script a lynx session -
> expect, kermit, probably emacs... not that I've tried.

It seems to be something that people ask for on occasion, but I agree
it can/should be done outside of Lynx.

> > It could still be a fun extra patch to have around and not included in
> > the src distribution.
> 
> Sure, go ahead...

I'm just a codemangler who gets things right every now and then, I'd
be around a while messing around with that.  

Remind me to rm fortune for slapping me with this quote after I say
that...

-- 
"We have more ability than willpower, and it is often an excuse to ourselves
 that we imagine that things are impossible."
                                - Francois Duc Deu Rochefoucauld