Plume Patches

Note: Much of my attention is going to be moved to Quill...

The browser situation on Unix, IMHO, is pathetic. It's either Netscape/Mozilla or slow, buggy crud. ("Oh, and Netscape isn't?") And is Gecko going to be a solution? I'm afraid Gecko will die of Netscape's own success. There's so much rubbish out there that relies on Netscape's misfeatures (e.g. just about anything made by Cyberplex), that for Gecko to conform to the W3C it's either going to have to break those sites (in which case, nobody will use it, blaming the browser instead of the source of the excrement), or it will have to be heavily haywired for compatibility (in which case it will be bloated, slow, buggy, and difficult to reuse).

Opera may one day produce an excellent Unix browser, but frankly I'm not going to hold my breath for a NetBSD version.

One with great potential is KDE's kfm. I say potential, because it has a few nasty bugs:

its URI handling is sloppy (trailing slashes and %-codes are treated very haphazardly) and
URI resolution is bogus (failing on most of the references on this page, which all conform to RFC-2396) [PS: they've handled my bug reports on that];
its forms are broken;
its file scheme will show index.html in place of a directory listing, a decided lose in a File Manager (in fact this was a motivator for my x-file scheme);
there's no presentation of LINKs (a very rare feature, and one of the things that drew me to Plume);
there's no way to turn off the automatic loading of inlined images (this seems to be a very rare feature on Unix browsers);
there's no override for document colours, so the user is effectively locked into a black-on-white colour scheme because of the enormous number of idiots using BGCOLOR alone.

So why don't I fix it myself? It's buried in something like 20 MB of C++ source; I have no time to download and hack such a beast, and then wrestle to get the patches accepted.

I've also tried Arena and Chimera. Arena has a decent if prototypical HTML renderer, with some CSS awareness; but it tends to crash and Arena's toolbar is a bogosity. Chimera is actually surprisingly good, all things considered; it managed to be my main browser on NetBSD/Amiga. It even has the option to turn off automatic inline loading. But, it too tended to crash (although not excruciatingly often) and, being written in C, there's a painful tweak-compile-tweak-compile cycle.

And of course there's the old standby Lynx. I use it often, because often nothing else works. It's my only browser with reliable forms.

In short: I have no reliable graphical browser.

Enter Plume

And then there's [Maude... smack] Plume. It's nothing to rave about, by any means; BUT it's written in something that is very easily extensible and debuggable (especially by someone green to the code at hand - you can jamb the most delightful call stack traces and whatnots into it with the twitch of a finger).

One terrific thing about Plume right from the get-go was its presentation of LINKs. I know of no other browser that does this (I'm sure they exist - somewhere). And I keep LINKs in each document for easy access to the validators... or at least, it would be easy if browsers did what the splat they were supposed to do.

So I set to to make what repairs I could. Here're some of the major ones:

Relative Redirections: Although it's illegal, many servers send out relative Location:s in their HTTP redirections, e.g. RSAC. Plume didn't handle them.
Content type cleaning: Plume only handled the foo/bar strings in Content-type:s, choking on the legal parameters sent by servers such as the W3C's.
Miscellaneous Quoting: Lots of quoting handling wasn't done just right - both %-coding in URIs and &-coding; in HTML. It was the kind of thing that didn't break often but was crippling when it did; eg if you're old enough, try to explore Lava Dome IV's FTP site. Completely new directory and FTP listing generators solved most of those problems.
URI handling: URI resolution was better than kfm's, but still had some flaws. This anchor to Furnation would break, because Plume tacked on another solidus and Furnation is sensitive to that (I'm not sure Furnation's behaviour is invalid, in fact I doubt it; but Plume's definitely was.)
Multihomed hosts: To stave off the extinction of available IP addresses a few hours, HTTP/1.1 supports having several HTTP sites on a single IP. The server knows which site is being requested by the inclusion of a Host: line or by submission of an absolute URI. Plume did neither. This is in flux; I got a little ahead of myself and just send URLs instead of a URI and a Host. Many servers already support it (HTTP/1.1 servers are required to), but it's not strictly correct (HTTP/1.1 clients must stick to URI/Host pairs). Amazon.com is a site that breaks, so I'm motivated to fix it. :)
FTP rewrite: FTP is now implemented using Steffen Træger's package. It's still in a bit of flux; the package only does Get to a file and I haven't worked out the right way to handle that. (HTTP also always loads to a file, for binary-uncleanness reasons which no longer exist. I'll probably preserve it and mirror it in FTP. Or, heck, I'll check how it used to be done.)

There is, of course, much yet to be done:

A decent HTML rendering: There are problems intrinsic to using Texts to display HTML, such as the limitations on scrolling vs. tall inlined images and tables. Never mind that Plume's HTML rendering has some major problems with tables; it would in fact probably be better to remove the attempt at tables altogether, and look for a better HTML widget in C; D. Richard Hipp's is pretty promising.
Cookies: Some places just won't work without cookies. And some places won't work even with them; ChaptersGlobe is yet another of Cyberplex's china dolls which claims it's looking for cookies when it's actually looking for Netscape. (It would refuse to work with Opera until Opera recently changed its User-agent. In fact, the first cookie it sends me accompanies the page saying I have to enable my cookies; in other words it doesn't even splatting test for cookies until it's decided you haven't got them. And that one page it will send, contains no entity to which to send complaints. That's fairly typical of Cyberplex's incompetence. And how much you wanna bet they rely on persistent cookies, aka cookie jars, which are contrary to Netscape's own RFC-2109! Plus, their cookies are syntactically invalid - one is sent as Set-Cookie: SITESERVER=ID=blablah...; that second = is contrary to section 4.1 of RFC-2109. And, it's one of those sites that engages in illegal relative redirecting. If I can get Plume to fool that junkpile into operating, I'll have done something. The ChaptersGlobe site got Internet World 1999 Site of the Year... which just goes to show what Internet World knows.) Boycott in favour of Amazon.com which likes to use cookies, but doesn't require them. (IMO the Amazon people are very good at what they do. Unfortunately, Amazon fails just now with my Multihomed host handling...)
Configurable/selectable User-agent: See Cookies.
Bookmarks: What kind of sodding browser has no bookmarks? Plume, that's what. :)

The Patches

To the gritty-nitty, as Mrs. Slocum would say.

Install Plume 0.6.2a, then apply the patches - last uploaded 1999 Jun 28 - to the library directory in the obvious order. Indeed,

cat *.patch|(cd libdir;patch)

will likely do the job. I'm talking Unix, of course...

Two external packages are required: Steffen Træger's FTP, and my own HCLS of needful things.

Jan Nÿtmans' Img extension is not required but very desireable.

Bonne chance!

The X-File Scheme

Any connection you make to Chris Carter's sit'com' is strictly between us, okay?

I'm going to put a pretty formal description of this scheme here one day...

Afterthought

Their plan will be unfurled... -- Pinky and The Brain theme. (kfm makes no presentation of the Q element there, especially its CITE attribute. Does your browser? Will Plume? Stay Tooned... :) )

Here's one of those "delights" I jammed into Plume at one point. Make it the first thing your script does and watch that call stack unfurl.

rename proc PROC
PROC proc {n v c} {
	if {[string match ::* $n]} {
		set z $n
	} else {
		set z [uplevel 1 {namespace current}]
		if {![string match *:: $z]} { append z :: }
		append z $n
	}
	PROC $z $v [subst -nocommands {
		puts "[format %[expr {2*[info level]-2}]s {}]$z"
		$c
	}]
}

Try doing THAT in anything other than Lisp... It's not perfectly robust, but it showed me just beeyoutifully what was calling what. (I use that format trick because string repeat is too new.)