[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OverbiteNX

Greetings.

thank  you  Cameron for your work. I have discussed the webextension ap‐
proach with the author of surf2, where he needed to write extensions  to
handle  everything  the  webkit  developers did wrong in the API for we‐
bkit2.

We think the native protocol handler war is lost. There are two ways:

1.) Make some extension to a central point like

	proxy.gopherproject.org/%s

This would redirect to official proxies.

(See: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/protocol_handlers)

2.) Teach people how to change the handlers for gopher://. This is not easy
    since Mozilla removed the ability to easily add a protocol in the
    application configuration. Maybe it can be automated with some simple JSON
    extension too.

WARNING:  For  those who only wanted to read the useful content of my e‐
mail, stop reading now. A rant on feature bloat and  web  insanity  fol‐
lows.

On Sun, 21 Jan 2018 13:53:00 +0100 Ciprian Dorin Craciun <ciprian.craciun@gmail.com> wrote:
> * perhaps it would be best to document the protocol your extension
> uses to talk with the "native process", which most likely is JSON
> based;  this way one can simply provide an alternative implementation;
> 
> * if going the Python / Perl / Ruby / "other interpreted language"
> way, then it would be nice if it didn't require any external library
> (except the interpreter itself, and hopefully that language is already
> installed on may distributions);  if this isn't the case it would be
> nice to have a documented way on how to prepare a "virtual
> environment" so that one doesn't need to juggle RPM / DEB files;  (on
> a second thought one could just use NodeJS and the whole "run-time"
> needed is the `node` executable, even on Windows;)
> 
> * perhaps, given how simple the Gopher protocol is, one could just
> implement the whole "native process" in Go / Rust, thus it will not
> require any extra libraries;  (I excluded C because Go / Rust are more
> "portable", thus easily compilable on OSX / Windows;)

C is the best solution here. It is easy to read. C got its »bad« reputa‐
tion because of people using it wrong. First  make  the  problem  small,
then implement. With gopher a simple problem is given, except:

> Now on a different matter:  what other opportunities would this
> "native process" open?

This  already  starts  a bad path. Please, this is just about having the
good old gopher support in webbrowsers. Don’t try a revolution. This  is
how the web got wrong, everythong got wrong. If you really do it, please
use CORBA or DCOM instead of SOAP.

> For starters I think the main appeal of Gopher is that it "simplifies
> and cleans the Internet", i.e. no jumping adds, no million ways to
> create and navigate a menu, etc.  Instead it brings order: menus with
> clear semantic, a search functionality, and the rest are documents.
> 
> Thus how about this:  instead of the "native process" being just a
> dumb TCP socket proxy, why don't we transform it into the "Gopher
> protocol backend" by doing the following:

No,  no,  simply  now.  You are thinking too far. This is the disease of
modern software development. God is not in every problem out there. Once
a problem is solved. Don’t add a church and a religion to everything.

> * specifying in JSON a format for describing the Gopher menus (and
> related) -- it shouldn't be hard as I bet inside the extension there
> is already such a structure;  (this also cleans and enables things
> such as headers, etc., which today are twisted and clobbered
> selectors;)

Gopher menus, as a native format, are easier to parse than JSON. JSON is
the tickle down effect of the web. First people of the  web  should  get
MIME right instead of adding more crap.

> So what does all this enables?  By replacing the "native process" with
> a different one --- that keeps the Gopher "semantic" --- one can
> provide alternative Gopher protocol implementations;  Gopher proxies
> to other non-Gopher-native services without requiring one to run a
> gopher proxy;  and other experimental things;
> 
> Concrete example:  I remember some time ago some discussions about
> Gopher over TLS.  This would be easily achievable by changing the
> "native process" without touching the extension itself.

The  goal here is to only have gopher support for some really ugly soft‐
ware base (i.e. firefox and chromium). Firefox and chromium need to  die
in the long run. Their encapsulation of simple code logic in objects ev‐
erywhere adds unneeded sloc. You are adding yet another layer  of  indi‐
rection  noone  will ever use besides the short‐sighted enlightenment in
your mind.

Please,  just leave those extensions to only support gopher. Firefox and
chromium already betrayed us too often, by changing their API,  abandon‐
ing gopher native protocol support without a good reason etc.. They will
betray us again out of their incompetence. So keep the abstraction layer
simple  and  perfect.  People after you need to maintain this. When it’s
done and has all features, stop and only maintain.

Adding  something  like  TLS will require more clients to be changed. If
this stays a webbrowser‐only change, the small gopherspace is  split  up
because  of  the consumerist small‐sighted view of web users. The web is
not the end goal, gopher is. This is not a museum, it's reality.

> And an additional idea:  how about the Gopher extension starts using
> actual URL's in its menus instead of two separate host and port
> fields?  (This would enable easily implementing "virtual" Gopher
> servers, by intercepting these URL's within the native process.)

Writing  your  »virtual«  gopher  server will only bloat logic and waste
precious energy generated out of resources we could have used for  colo‐
nizing planets.

Simply do:

	geomyidae -b $(pwd)

and  you  have  a  »real«  gopher server. The JSON‐encapsulation virtual
cloud‐based hyper‐scalable uber‐microservice solution will not be  liked
by  anyone  else. You will only see people vomitting and using it for an
example how to not solve solutions.

> How about it doesn't "choose" the content type of a resource
> beforehand based on what someone wrote in the menu selector, but
> instead uses that as a hint for icon purposes, but when the response
> comes in, it actually "finds-out" (via a `Content-Type` marker in the
> "native process" protocol) about the actual resource type.

If  you want HTTP, you know where to find it. Don’t make gopher HTTP. We
already have HTTP and know how it did end.

> This would allow the owner of the Gopher resource to change its type
> (for example from TXT to HTML) without breaking all selectors pointing
> to that resource.

This dream does not work and will never work.

> I hope this opportunity isn't missed by the Gopher community to evolve
> the Gopher universe farther than it's 1990 technical limitations
> allowed --- keeping its semantic roots (simplicity and cleanness), but
> upgrading its antiquated technical-related aspects to 2018 (the
> protocol and all accumulated quirks)!

I  hope  this »opportunity« is missed and gopher stays at the sane level
it is now.

> I say this, because so far any evolution was "terminated" mainly by
> the "all Gopher browsers would have to be changed and upgraded, thus
> this change is breaking the Gopherspace";  well today the main "Gopher
> browser" is already broken...

You  haven’t  followed  the  active gopher community lately. We now have
sacc, clic and more browser evolving out of the gopher principle of  its
simplicity.   Someone proposed patches for elinks. There are active peo‐
ple who can change the »old« clients. Well, those are the sane  clients.
Text interfaces are freedom.

Look at the web where it evolves when you have some undocumented commit‐
tee deciding about too complex standards noone can implement in one day.
Standards should be that simple. This is our freedom.  The complexity of
the W3C is now leaning towards an oligopoly of firefox and  chrome.  The
sourcecode  is  too  complex for anyone sane to propose a change and the
developers are corrupted  by  their  lords  paying  them  their  monthly
salary.


Sincerely,

Christoph Lohmann
Reply to: