skxpl | 1 Jul 22:15 2008

Re: GoperVR for Linux "works"

sonicmctails@... writes:

> I'll post screenshots if anyone is interested

I would love to see some screenshots and would definitely use GopherVR if 
there was a version for Linux.

--

-- 
skx, http://skxpl.eu.org

David Meyer | 3 Jul 16:52 2008

First impression of OverbiteFF

Wow!

I finally bit the bullet and upgraded to Firefox 3 so I could 
take a look at this vaunted plug-in we've been talking about.

I think I have a new favorite GUI Gopher client.

Great job, Cameron.
--

-- 
David Meyer
Takarazuka, Japan
gopher://sdf.lonestar.org:70/1/users/papa
papa@...

brian | 4 Jul 19:32 2008
Picon

Serving up gopher content via a wiki

As time permits I've been working on a proof-of-concept for serving up
gopher content via a wiki.  I'm one of the devs that works on
WikkaWiki (http://www.wikkawiki.org), so naturally that is the
framework on which I'm developing. 

My rationale for going in this direction, as well as some supporting
notes, can be found at http://www.wikkawiki.org/WikkaGopher.  I
believe the resurgence of gopher will depend upon a number of
different approaches; this represents my contribution.

I have a test page that can be accessed at
http://wikkacase.org/wiki/GopherTest.  Please keep in mind the key
phrase "proof of concept."  Not all selectors have been implememted
(rudimentary navigation should work, as well as text files downloads).

Comments appreciated...you can comment here, or right on the
GopherTest page (you'll need to register a username first).  

  --Brian

Cameron Kaiser | 5 Jul 00:16 2008

meta: item types, etc.

I've been having back-channel discussions with gopher wranglers who note that
the item types they have selected for their content, while working in Mozilla
due to content sniffing, don't work in Overbite which rigidly enforces its
particular internal set (all others being seen as application/octet-stream).

Although I made some token expansion with the p and d item types, at some
point there is going to need to be an expanded and formalized item type and
MIME type mapping list maintained by a central authority or this problem is
going to come up again. I think it is especially important now given that
there are others looking at creating their own particular clients, since it
would be very confusing for users to have clashing item types between apps.

This is something I don't mind being a point person and clearinghouse for,
but that aside, a formalized process for this needs to be devised.

--

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@...
-- Who are you going to believe, me or your own eyes? -- Groucho Marx ---------

JumpJet Mailbox | 5 Jul 04:14 2008
Picon

Re: meta: item types, etc.

I am absolutely, 100%, AGAINST the idea of Upper / Lower case letters indicating different Item Types. 
Although this may be acceptable for some computer platforms (upper and lower case letters do have
different ASCII values), it is a real annoyance on others.  As protocols must be universal, "case
neutrality" should be the only acceptable method.
 
JumpJet proposes the following:
Type 1 = "directory"
Type i or I = "information"
 
Type 0 = "Plain text file"
         
 

--- On Fri, 7/4/08, Cameron Kaiser <spectre@...> wrote:

From: Cameron Kaiser <spectre@...>
Subject: [gopher] meta: item types, etc.
To: gopher@...
Date: Friday, July 4, 2008, 6:16 PM

I've been having back-channel discussions with gopher wranglers who note
that
the item types they have selected for their content, while working in Mozilla
due to content sniffing, don't work in Overbite which rigidly enforces its
particular internal set (all others being seen as application/octet-stream).

Although I made some token expansion with the p and d item types, at some
point there is going to need to be an expanded and formalized item type and
MIME type mapping list maintained by a central authority or this problem is
going to come up again. I think it is especially important now given that
(Continue reading)

JumpJet Mailbox | 5 Jul 04:14 2008
Picon

Re: meta: item types, etc.

I am absolutely, 100%, AGAINST the idea of Upper / Lower case letters indicating different Item Types. 
Although this may be acceptable for some computer platforms (upper and lower case letters do have
different ASCII values), it is a real annoyance on others.  As protocols must be universal, "case
neutrality" should be the only acceptable method.
 
JumpJet proposes the following:
Type 1 = "directory"
Type i or I = "information"
 
Type 0 = "Plain text file"
               
 

--- On Fri, 7/4/08, Cameron Kaiser <spectre@...> wrote:

From: Cameron Kaiser <spectre@...>
Subject: [gopher] meta: item types, etc.
To: gopher@...
Date: Friday, July 4, 2008, 6:16 PM

I've been having back-channel discussions with gopher wranglers who note
that
the item types they have selected for their content, while working in Mozilla
due to content sniffing, don't work in Overbite which rigidly enforces its
particular internal set (all others being seen as application/octet-stream).

Although I made some token expansion with the p and d item types, at some
point there is going to need to be an expanded and formalized item type and
MIME type mapping list maintained by a central authority or this problem is
going to come up again. I think it is especially important now given that
(Continue reading)

JumpJet Mailbox | 5 Jul 04:14 2008
Picon

Re: meta: item types, etc.

I am absolutely, 100%, AGAINST the idea of Upper / Lower case letters indicating different Item Types. 
Although this may be acceptable for some computer platforms (upper and lower case letters do have
different ASCII values), it is a real annoyance on others.  As protocols must be universal, "case
neutrality" should be the only acceptable method.
 
JumpJet proposes the following:
Type 1 = "directory"
Type i or I = "information"
 
Type 0 = "Plain text file"
              
 

--- On Fri, 7/4/08, Cameron Kaiser <spectre@...> wrote:

From: Cameron Kaiser <spectre@...>
Subject: [gopher] meta: item types, etc.
To: gopher@...
Date: Friday, July 4, 2008, 6:16 PM

I've been having back-channel discussions with gopher wranglers who note
that
the item types they have selected for their content, while working in Mozilla
due to content sniffing, don't work in Overbite which rigidly enforces its
particular internal set (all others being seen as application/octet-stream).

Although I made some token expansion with the p and d item types, at some
point there is going to need to be an expanded and formalized item type and
MIME type mapping list maintained by a central authority or this problem is
going to come up again. I think it is especially important now given that
(Continue reading)

JumpJet Mailbox | 5 Jul 04:14 2008
Picon

Re: meta: item types, etc.

I am absolutely, 100%, AGAINST the idea of Upper / Lower case letters indicating different Item Types. 
Although this may be acceptable for some computer platforms (upper and lower case letters do have
different ASCII values), it is a real annoyance on others.  As protocols must be universal, "case
neutrality" should be the only acceptable method.
 
JumpJet proposes the following:
Type 1 = "directory"
Type i or I = "information"
 
Type 0 = "Plain text file"
    
 

--- On Fri, 7/4/08, Cameron Kaiser <spectre@...> wrote:

From: Cameron Kaiser <spectre@...>
Subject: [gopher] meta: item types, etc.
To: gopher@...
Date: Friday, July 4, 2008, 6:16 PM

I've been having back-channel discussions with gopher wranglers who note
that
the item types they have selected for their content, while working in Mozilla
due to content sniffing, don't work in Overbite which rigidly enforces its
particular internal set (all others being seen as application/octet-stream).

Although I made some token expansion with the p and d item types, at some
point there is going to need to be an expanded and formalized item type and
MIME type mapping list maintained by a central authority or this problem is
going to come up again. I think it is especially important now given that
(Continue reading)

JumpJet Mailbox | 5 Jul 04:14 2008
Picon

Re: meta: item types, etc.

I am absolutely, 100%, AGAINST the idea of Upper / Lower case letters indicating different Item Types. 
Although this may be acceptable for some computer platforms (upper and lower case letters do have
different ASCII values), it is a real annoyance on others.  As protocols must be universal, "case
neutrality" should be the only acceptable method.
 
JumpJet proposes the following:
Type 1 = "directory"
Type i or I = "information"
 
Type 0 = "Plain text file"
       
 

--- On Fri, 7/4/08, Cameron Kaiser <spectre@...> wrote:

From: Cameron Kaiser <spectre@...>
Subject: [gopher] meta: item types, etc.
To: gopher@...
Date: Friday, July 4, 2008, 6:16 PM

I've been having back-channel discussions with gopher wranglers who note
that
the item types they have selected for their content, while working in Mozilla
due to content sniffing, don't work in Overbite which rigidly enforces its
particular internal set (all others being seen as application/octet-stream).

Although I made some token expansion with the p and d item types, at some
point there is going to need to be an expanded and formalized item type and
MIME type mapping list maintained by a central authority or this problem is
going to come up again. I think it is especially important now given that
(Continue reading)

JumpJet Mailbox | 5 Jul 04:14 2008
Picon

Re: meta: item types, etc.

I am absolutely, 100%, AGAINST the idea of Upper / Lower case letters indicating different Item Types. 
Although this may be acceptable for some computer platforms (upper and lower case letters do have
different ASCII values), it is a real annoyance on others.  As protocols must be universal, "case
neutrality" should be the only acceptable method.
 
JumpJet proposes the following:
Type 1 = "directory"
Type i or I = "information"
 
Type 0 = "Plain text file"
                  
 

--- On Fri, 7/4/08, Cameron Kaiser <spectre@...> wrote:

From: Cameron Kaiser <spectre@...>
Subject: [gopher] meta: item types, etc.
To: gopher@...
Date: Friday, July 4, 2008, 6:16 PM

I've been having back-channel discussions with gopher wranglers who note
that
the item types they have selected for their content, while working in Mozilla
due to content sniffing, don't work in Overbite which rigidly enforces its
particular internal set (all others being seen as application/octet-stream).

Although I made some token expansion with the p and d item types, at some
point there is going to need to be an expanded and formalized item type and
MIME type mapping list maintained by a central authority or this problem is
going to come up again. I think it is especially important now given that
(Continue reading)


Gmane