From: Cameron Kaiser <spectre@floodgap.com>
Message-Id: <200801161600.m0GG00qD011820@floodgap.com>
Subject: [gopher] Re: Strategy: end of Gopher in Mozilla
In-Reply-To: <20080116084920.083ed2a7@work1.hal3000.cx> from Chris at "Jan 16,
 8 08:49:20 am"
To: gopher@complete.org
Date: Wed, 16 Jan 2008 08:00:00 -0800 (PST)
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org

> Opera through squid works quite well, however since I run my squid locally
> this doesn't help. Jeff P and I had worked on gnetcat as a proxy run
> locally, but gnetcat isn't a solution for MS people. Jeff Had some Mirc
> code for a proxy to run locally as well. But in the long run, one might feel
> having a casual user run his own proxy might not appeal to many.

Yeah, it does seem iffy. However, do I take this to read that there is a
gopher proxy option somewhere in the bowels of WinINet?

> Lynx has always worked well.
> Having people run old browsers is an option, but since moz was broke
> (bug 158888), might I suggest , if thats the path, to consider advising
> people to use browsers that "do ports" properly?
> As for a FF add-on I think it'd be nice to go our seperate ways.
> But then your missing all these people who we (need?) to keep gopher alive.
> There are by my count 107 gopher servers around as of 01/09/08,

Actually, my count is 153 (!). There is an impending purge but there are
only around five or six suspects marked for deletion.

Do note some of those are CNAMEs, of course -- I go by name because the old
IP-address system the original Veronica used left a lot of indeterminate
orphans.

> And we all know there is usefull info to be had and the protocol is decent
> sound stable and simple. Maybe we have a chance to grow something that many
> can use but I dont think we are going to loose the people we have already
> from this. Should we on the list all take a head count of various browsers
> we use first and see if maybe we are missing another option? I wonder do we
> want a cross protocol browser? If so must it do JS and MMFlash? Does it
> need to run on MS and *nix and ?? . 

I think there are a few things we can take as semi-axiomatic:

- We, the true believers :), will use whatever client works well and are
willing to make the effort to go get a client that works well if the one
we use does not.

- The casual browsing public ("d00d! g0ph3r is 5o r3tr0!!1!") are going to
stick with what they have and don't want to be inconvenienced.

- The IE-only crowd is lost. Those people will have to use a proxy, if
they even think of it.

- The Firefox crowd is at least used to downloading extensions.

- We want to impose as minimum a migration burden on users as possible.

I use Camino instead of Firefox as my daily browser and that has little or
no extension capability, so any FF-oriented add-on would not be in my
constituency. That said, however, based on what I think we can take on faith,
an FF-based add-on would work anywhere FF is supported and would incur the
least inconvenience for users.

At least, even if inadvertently, the Moz devs did us a favour -- since 2.0 is
going to break API compatibility in some places, we can target that and not
have to worry about Moz 1.9 support.

Mind you, I do still want to create a stand-alone client because some things
like Gopher+ views -- and if we're going to do this right, we should be
implementing Gopher+, something that I am officially putting back into the
Bucktooth roadmap for server support -- are just impossibly kludgey in a
web-browser environment. However, if people have ideas to implement this
effectively, I'm all ears. Also, we're at the mercy of FF's API support and
there is no guarantee they're not going to break our backs again because
we more than the other more cosmetic plugins are likely to rely on lower-level
calls that are going to be subject to scrutiny and sometimes drastic
revision. So myself my ultimate goal is to get to a stand-alone app once
people are comfortably migrated out of stock Mozilla installs.

> One other thought, go back in time to a browser which worked best, best on
> the web and best in gopher (ports!) and take it and make a dev from that
> point of development branching off with a commitment to Gopher and a
> (weaker?) commitment to html.

I think that's going to be a boondoggle. I understand the motivation and I
appreciate it, but consider how many people are actually going to use a
browser of that sort. Like it or not, the largest member pool of the gopher
constituency are going to be occasional browsers who spend the majority of
their time in HTML. A browser that does not recognize this is going to lock
out a lot of people who just won't find it worth it when Gopher to them is
something optional.

If we make the 'fee' to stay in the Gopher fold as low as possible, and
the barrier to entry reasonable, *and start getting this through now*, we
can avoid serious attrition.

> I think that when a project gets so big that it moves from vote based
> prioritization to vote based acceptance for bugs you have a real problem
> anyhow, so to me the least desirable way would be for us to remain dependent
> on a large group that for the most part has no interest in our "niche" (and
> all the other crap they stated).

I can understand Mozilla's (and Brendan's) desire to strip out chaff from
Gecko, but this kind of cannibalization is ultimately going to be
shortsighted, and the definition of chaff seems to be 'anything the devs
don't use on a regular basis.' The vote system is routinely ignored anyway.
High vote items are still done on a time basis, and zero-vote items are
booted up the priority chain if a Moz dev with pull wants it in. We had
one vote to yank Gopher, compared with all the HTML rendering bugs that
sometimes have tens or hundreds, and guess which one gets chosen and why?

Still, a recognition of reality for the short term can still bring people
into our fold and then we can migrate them into an ecosystem better controlled
by the gopher community where our needs come first. We can use FF as a
transitional step and get as much benefit out of the remaining support as
we can, get people into an external plug-in for FF4, and then start moving
those people into a custom client so that we are insulated from the inevitable
screwage of the API in future Firefoxen.

In the short term, this is what *I*'m going to be doing:

- Starting internal design on simultaneous FF plugin and a stand-alone
executable. I'll christen my work "Overbite" and "OverbiteFF". The
stand-alone is likely to surface first, and on purpose, so that people will
know that such a client is available. The OverbiteFF plugin will appear as
Mozilla 2.0 starts to gel. When I have something to play with, I will
notify. I would like to use AIR, but I might use RealBASIC for a prototype
instead since AIR is still beta, and migrate later. Whatever we do must be
cross-platform (Windows alone won't cut it and I think we should have Linux
support too -- and I'm a Mac bigot so a Mac OS X version is a given :).

- It appears that wanted-1.9 is off the bug, so barring a sudden burst of
disingeniuity from the Moz devs, we can start publicizing to people that
Firefox 3 will be the final version to support gopher and directing people
to alternatives that exist now. JumpJet has their gopher client archive, I
have my Public Proxy, anyone else? All of us running servers should let people
know of the impending change so that regular gopher users can be aware of it,
but I think we should wait to start going public on it until 388195 has
stabilized and the path is clear. That should be later this week.

Other comments?

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@floodgap.com
-- Glory is fleeting, but obscurity is forever. -- Napoleon Bonaparte ---------