[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