Cameron Kaiser | 1 Aug 01:13 2008

Re: FYI: Gopher Service Stats Summary

> Has anyone seen this?
> Accidently ran across this Gopher Service Stats Summary log posted=A0to t=
he web.
> http://www.dna.affrc.go.jp/statistics/gopher.cnt.html

Encouraging to see a very 'specialized' server like this one getting so
much traffic.

--=20
------------------------------------ personal: http://www.cameronkaiser.com=
/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser <at> floodgap.c=
om
-- Never explain, never apologise. -- John Arbuthnot "Jackie" Fisher ------=
----

Kyevan | 3 Aug 02:24 2008

Re: gopherchan!

This is rather neat... but you should note there's already a 1chan.

http://www.1chan.net/

... Actually, I think there are a couple other 1chans, too. Gopherchan 
would probably be a better name, really.

Mate Nagy wrote:
> Hello,                                                                                                                       
>  pls note that this is not entirely serious :) (more like an experiment                                                      
> with the Kaya programming language: www.kayalang.org)                                                                        
>  ..but: gopher://port70.net/1chan                                                                                            
>                                                                                                                              
> Regards,                                                                                                                     
>  Mate
> 
> 

Kyevan | 3 Aug 03:18 2008

Re: Item Type Suggestions

What about the whole world of text-based formats? (text/*)?

I think it might make most sense to put text/* under 1, application/* 
under 9, image/* under I, and audio/* under s.

As a practical matter, for the moment, it might be easiest to just 
prohibit message/* and multipart/*, since the only use I can see 
gopher-wise would be multipart/appledouble, and there it makes more 
sense to use binhex and item type 4. example/* and */example are 
entirely invalid (outside documentation), of course!

video/* and model/* could be either shoved under 9, or we could define 
item types for them. Having item types that parallel the base Internet 
media types seems like it would make sense and would ease conversion... 
but would possibly break compatibility with older clients. Actually, I 
and s have that problem too, though they're wide-spread enough to be 
mentioned on Wikipedia (which, admittedly, could just be one editor 
using them...)

Add fallback types to the hypothetical pie-in-the-sky Gopher Perfect 
that will be specified around the same time as all that vaporware we've 
been 'promised' over the years comes out, I guess. :P

Additionaly, might we want to use something like 
application/[X-]gopher-menu as a type for 0? I mean, it seems like it 
would be nice to have SOMETHING to put in a MIME type-related field for 
menus, if for no other reason than to look nicer to humans reading the 
menu... and besides, then you could do stupid things like return gopher 
menus over http :P

(Continue reading)

Kyevan | 3 Aug 04:04 2008

Re: Establishment of .gopher TLD

"Sites hosted on a .gopher domain should not serve content via any other 
protocol."

What's your reasoning for that? I mean, Gopher should be primary, but I 
don't see an issue with, say, turning on the http access in pygopherd or 
using some other proxy, or running sshd for remote administration, or such.

brian@... wrote:
> OpenNIC is an alternative, open, democratic DNS that mirrors the ICANN
> namespace as well as provides namespaces for alternative TLDs.

Except ICANN's .biz, last I looked. This may have changed now that 
PacRoot is dead, though.

Matthew Holevinski wrote:
 > Honestly I think that's a fabulous idea.
 > There's no reason gopher has to be restricted
 > to Gopher://.

Except that whatever:// is actually for the client only, so it knows if 
it needs to send a gopher selectorm http's multitude of headers, 
negotiate an ssh connection, or fire up Unreal Tournament for a 
deathmatch ;)

brian | 3 Aug 03:46 2008
Picon

Re: Establishment of .gopher TLD

On Sat, Aug 02, 2008 at 09:04:46PM -0500, Kyevan wrote:
> What's your reasoning for that? I mean, Gopher should be primary, but I 
> don't see an issue with, say, turning on the http access in pygopherd or 
> using some other proxy, or running sshd for remote administration, or such.

Kyevan, permit me to post the same response to another individual who
raised the same question:

    Good point...although while I've heard of "gopherspace," I've not               heard of "httpspace," "ftpspace,",
"telnetspace," etc.                                                                                
    There's nothing stopping the introduction of protocol-based TLDs...but          I think motivation is
important:  My desire to introduce .gopher is to          help reinvigorate the movement to bring gopher back to the
masses.              The http protocol doesn't need such a boost, neither does ftp, telnet,          smtp, etc.

> Except ICANN's .biz, last I looked. This may have changed now that 
> PacRoot is dead, though.

OpenNIC had .biz before ICANN laid claim to it.  So we consider it a collider

> Except that whatever:// is actually for the client only, so it knows if 
> it needs to send a gopher selectorm http's multitude of headers, 
> negotiate an ssh connection, or fire up Unreal Tournament for a 
> deathmatch ;)

But clients could take advantage of a .gopher TLD if they were
configured to do so, so the point is valid, just not in the context of
most (all?) current browsers.

  --Brian

(Continue reading)

Nuno J. Silva | 3 Aug 18:01 2008
Picon

Re: Gopherness

On Sun, 20 Jul 2008 17:15:48 -0500
Kyevan <kyevan@...> wrote:

> Interesting, but there are three things that I have reservations or=20
> questions about.
>=20
> > - Putting "up" or "previous menu" items in menus which points into
> > your personal "data island".
>=20
> Often times, pointing back up a tree makes sense, even if that's not
> the tree the user followed to get here. I think the issue is probably
> more with the title than the idea of putting a link to a menu 'above'
> this one.

I would place such a feature in the gopher client itself, something
like 'goto parent menu' and 'goto server root'.

<snip/>=20
>  > - Rendering Everything Else to a Handful of Established Types.
>=20
> The problem here is that you're assuming all, for example, images are=20
> equal. JPEG works pretty well for photographs or 3d renders of
> lifelike scenes, but often makes drawings, charts, graphs, and the
> like unusable. This is the easiest to see, but even text has this

You can always set the jpeg quality to 100% when creating the file
(I don't know how much tools allow you to do that - at least the GIMP
and ImageMagick do it), but it might be useful to allow another image
type, for the examples you described. Although gif is associated with
'g', i'd pick png, as the former is proprietary. (How is that issue? Is
(Continue reading)

Matthew Holevinski | 3 Aug 18:33 2008
Picon

Re: Establishment of .gopher TLD

Well we could always abbreviate it to just .gop :))
but then again, someone might take offense.

Matt

On Sat, Aug 2, 2008 at 8:46 PM,  <brian@...> wrote:
> On Sat, Aug 02, 2008 at 09:04:46PM -0500, Kyevan wrote:
>> What's your reasoning for that? I mean, Gopher should be primary, but I
>> don't see an issue with, say, turning on the http access in pygopherd or
>> using some other proxy, or running sshd for remote administration, or such.
>
> Kyevan, permit me to post the same response to another individual who
> raised the same question:
>
>    Good point...although while I've heard of "gopherspace," I've not               heard of "httpspace," "ftpspace,",
"telnetspace," etc.
>    There's nothing stopping the introduction of protocol-based TLDs...but          I think motivation is
important:  My desire to introduce .gopher is to          help reinvigorate the movement to bring gopher back to the
masses.              The http protocol doesn't need such a boost, neither does ftp, telnet,          smtp, etc.
>
>> Except ICANN's .biz, last I looked. This may have changed now that
>> PacRoot is dead, though.
>
> OpenNIC had .biz before ICANN laid claim to it.  So we consider it a collider
>
>> Except that whatever:// is actually for the client only, so it knows if
>> it needs to send a gopher selectorm http's multitude of headers,
>> negotiate an ssh connection, or fire up Unreal Tournament for a
>> deathmatch ;)
>
(Continue reading)

Cameron Kaiser | 3 Aug 18:35 2008

Re: Establishment of .gopher TLD

> Well we could always abbreviate it to just .gop :))

Lol. No, I think you'd hear it about that one. ^_^

--

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@...
-- CONJUGATION OF THE HULKING ENTOMOLOGIST: I big / I bag / I have bug --------

Nuno J. Silva | 3 Aug 19:16 2008
Picon

Re: Item Type Suggestions

Mate Nagy <k-zed@...> writes:
<snip/>
>  About URLs: Someone has mentioned "relative links" in a previous mail -
> that was strange enough in itself, since there is no such thing in
> gopher. (Thus, it "cannot be broken"; and it especially cannot be broken
> in the server, which would put the mime bits in there itself, most
> probably after having generated the full selectors from all those
> relative links the content generator user supplied.)

An implementation of 'go up one level' command would be just eating
every char from the right side of the selector until a slash was
reached, and browsing that resource (which would be rendered as gopher
menu). (Although this might not work with some configuration, it would
work in lots of servers (right?))

We would have to add some sort of intelligence so when receiving an url
of this sort (the ones with the mime type), the client would just use
the part which is sent to server to get the 'one level above' url.

IIRC, the gopher protocol url has just one character for the data type,
the remaining of the url being used as the selector, when requesting the
data. Waiting for a parenthesis would break some servers, like sdf,
which uses selectors like 1/users for gopher://sdf-eu.org/11/users, and
expects '1/' to be sent (that being the expected procedure, rfc 1738
(and 4266 seems to state the same - gophertype is just one character)).

>  I would support a variation where we'd write off gopher+ as the
> complete failure it is, and just stick mime fields at the end of the
> menu records.

(Continue reading)

Mate Nagy | 3 Aug 21:23 2008
Picon

Re: Item Type Suggestions

Hulloh,
> A possible workaround: get the parent menu (using the same method I
> mentioned before - I don't remember anything stating the selectors are
> supposed to be built with a slash between each directory name, I need to
> read the rfc again (even if gopher is supposed to be hierarchical, what
> prevents some server from using dots instead of slashes for directory
> separators?)), check the mime-type (for the mime-in-the-menu approach),
> or check if the entry has gopher+ data (then retrieve such data).
 Exactly - you can't rely on '/' being the separator, or that the last
section cut off yields the valid parent dir, or even that there are
directories.

 At this point I'd much rather drop this protocol extension thing, and
focus on using the existing technology to the fullest.. whatever that
means :)

 ...
 For that matter, I'd love a client for Windows Mobile 6.. also for the
iphone 3G :) 

 On the server side: full text search engine. I have some experience
with using the HyperEstraier engine. I have about 16 gigabytes of text
indexed; I can search and view results over Gopher (with a python
"mole"), it's pretty fast and convenient. It also supports boolean
operators and phrase search.
 It doesn't have a Gopher spider currently per se, but it's fully open
source; maybe we could fit a spider to it? (Or even get the existing
Veronica spider to talk to it?)
 (Setting up and initializing the search db (from local data) is very
easy, so the required effort to play with it is minimal.)
(Continue reading)


Gmane