To me, this seems like a Job the Operating system should do, and we already do this in parts. The “urlwrapper” is a bit patched on, but still you can open urls and different applications can handle them.
I don’t think supporting severall protocols in one app is always the best idea, for example Renga and Vision do have major advantages over Chat-O-Matic because they only support the one protocol; That does not mean these projects can’t share code. But maybe they shouldn’t share all code, and we shouldn’t need to abstract everything.
In this case the design of WebPositive would become much more complex to support gopher, compared to a native client based on the existing netservices support.
I do agree with the goal to support gopher, but I do think it should be done seperately from html. Not because gopher is too complex, but because webkit forces our hand in severall design decision in WebPositive that makes supporting additional rendering engines hard.
So sure, if someone does provide a clean implementation and proves me wrong in that regard, yes that can be added. But I also don’t think this is feasible, and to me makes no sense over Making a good gopher browser next to WebPositive. (Hell, even shipping a native browser for gopher would be awesome. That gets way more exposure than “did you know WebPositive might support gopher depending on your haikuwebkit version and build flags?”. It gets it’s own entry in Deskbar and hopefully way better useability)