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

[Klaus Weide]

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.

> 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.

> 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.  :)

> > 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...

> Hmmmm.

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

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

Sure, go ahead...

    Klaus