[gopher] Updated Gopher RFC

Damien Carol damien.carol at gmail.com
Tue May 8 16:04:10 UTC 2012


Despite Cameron opinion, have more and more specific types IS NOT THE
SOLUTION.

See www, there have mime-type for that and it's a really really big mess.
No ? See that and cry =>
http://www.iana.org/assignments/media-types/index.html

If I see my crawler stats I can see that :
90% of gopherspace is 0 Text or 1 Menu elements...
7 % is Image generic type.
0,3 % is h URL: magic type

Other type are < 0,2%.

You see what I want to show ?

I think a more usefull thing will be to complete the RFC.
I mean tell WHAT CLIENT SHOULD DO FOR ALL TYPES.

For example give an algorithm to fix how client get ressources :

  *PROTOCOL ITSELF*



*Type*

*Description*

*What CLIENT MUST DO ?*

0

Short text, client can render it directly at screen because it's small data

Keep the menu and render the text directly

1

Menu the most important

Request the menu and analyse it





if it's a menu with '3' error node => show error message to the client





if not, then render the menu in new window

7

Index / Programs

Same as menu BUT the client send selector + TAB + something







*DATA NODES*



*Type*

*Description*

*What CLIENT MUST DO ?*

5

Binary crap

Download and analyse it

all others

Binary crap

if it's a menu with '3' error node => show error message to the client





If not the brower do what it want.





For example some browsers render images or redirect to other programs













*EXTERNAL*





*Type*

*Description*

*What CLIENT MUST DO ?*

h

external URL

Do what to do with "URL:"













*KEEP THIS FOR HISTORICAL REASON*



*Type*

*Description*

*What CLIENT MUST DO ?*

2

CSO phone-book server

Manage this nodes like h

8

Telnet session

Manage this nodes like h

T

tn3270 session

Manage this nodes like h


To be more constructive I think the good solution will be to have generic
types.

My proposal :

  *Old one*

*My Proposal*

*Name*

*Description*

1

1

MENU

Menu

0

0

TEXT

Small text file, render directly in browser in easy way

3

3

ERROR

Tell client that result is KO

7

7

INDEX / PROGRAMS

You now it

9

9

BINARY

Binary, generic one









5

5

ARCHIVE

Binary but check it as ARCHIVE (zip, rar, etc…)

g, P, I

I

Image File

Binary but check it as IMAGE (JPG, GIF, BMP, etc…)

;

V

Video File

Binary but check it as VIDEO (AVI, MKV, etc….)

s

A

Audio File

Binary but check it as AUDIO (WAV, mp3, etc…)

d

D

Document Text File

Binary but check it as TEXT (Plain, Word, ODF, etc…)









h

E

EXTERNAL URL

Check the selector for "URL:"

With this table the client can easily manage type and everything is simple.

2012/5/8 Cameron Kaiser <spectre at floodgap.com>

> > > Exactly.  There  is only a need for a menu type, informational,
> interac___
> > > tive (search), binary, uri (h), telnet, error  and text. The rest
>  could
> > > be  kept  for compatibility, but for example to support the non___GIF
> item
> > > type you have to implement heuristics anyway, which can be adopted
> for
> > > every  binary file.
> >
> > Maybe it's a good idea to have generic purpose-based item types, that
> > is, a way to say it's supposed to be viewed as an image, as a movie, a
> > document, a text file, etc.
> >
> > This would not be exactly as precise as a type that says "Compuserve GIF
> > image" or "Portable Network Graphics", but at least tells the client
> > "Hey, this is going to be an image, if you can, render it yourself or
> > delegate it to your imageviewer".
>
> We sort of have that with I (sort of), and ; and s, and (less widely
> accepted) d.
>
> --
> ------------------------------------ personal:
> http://www.cameronkaiser.com/ --
>  Cameron Kaiser * Floodgap Systems * www.floodgap.com *
> ckaiser at floodgap.com
> -- Everywhere is within walking distance if you have the time.
> ----------------
>
> _______________________________________________
> Gopher-Project mailing list
> Gopher-Project at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
>



-- 
Damien CAROL
gopher://dams.zapto.org/1/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gopher-project/attachments/20120508/6c06750f/attachment-0001.html>


More information about the Gopher-Project mailing list