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
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@...
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
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 ---------
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)
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)
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)
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)
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)
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)
RSS Feed14 | |
|---|---|
31 | |
5 | |
20 | |
10 | |
10 | |
13 | |
42 | |
31 | |
78 | |
452 | |
26 | |
10 | |
14 | |
5 | |
7 | |
1 | |
8 | |
69 | |
7 | |
31 | |
11 | |
17 | |
18 | |
45 | |
35 | |
4 | |
28 | |
33 | |
64 | |
36 | |
80 | |
42 | |
7 | |
22 | |
184 | |
10 | |
94 | |
41 | |
107 | |
36 | |
9 | |
77 | |
45 | |
5 | |
17 | |
11 | |
59 | |
50 | |
28 | |
13 | |
3 | |
19 | |
117 | |
176 | |
105 | |
44 | |
83 | |
17 | |
44 | |
47 | |
35 | |
37 | |
13 | |
1 | |
17 | |
36 | |
22 | |
6 | |
101 | |
9 | |
40 | |
7 | |
24 | |
19 | |
9 | |
18 | |
51 | |
9 | |
17 | |
13 | |
22 | |
3 | |
17 | |
30 | |
47 | |
22 | |
42 | |
8 | |
30 | |
8 | |
13 | |
8 | |
3 | |
12 | |
5 | |
22 | |
27 | |
19 | |
6 | |
8 | |
16 | |
7 | |
29 | |
4 | |
21 | |
21 | |
3 | |
4 | |
36 | |
9 | |
33 | |
4 | |
3 | |
12 | |
8 | |
5 | |
2 | |
6 | |
12 | |
12 | |
39 | |
34 | |
11 | |
11 | |
62 | |
65 | |
68 | |
143 | |
14 | |
6 | |
13 | |
2 | |
5 | |
23 | |
16 | |
10 | |
15 | |
2 | |
3 | |
122 | |
14 | |
1 |
