[gopher] Updated Gopher RFC

[zack mayson]

On 8 May 2012 17:04, Damien Carol <damien.carol at gmail.com> wrote:

> 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:"
>
> Sounds a bit like this April fool from the org-mode list:

 Org-mode and taskpaper <http://article.gmane.org/gmane.emacs.orgmode/6215>

and the follow-up to it:
Org-mode versus Taskpaper - now for
real<http://article.gmane.org/gmane.emacs.orgmode/6224>

(The point of the last one is that it is better for the user to be able to
'climb' in complexity rather than stuck at simplicity).

Anyway, in my view it is better to generalize for formats that don't have
their own types already (i.e. If a new image format pops up you add type
"IMG" and give the client the file's  extension; if the client decides it
can't understand it, it shows error to the user explaining why).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gopher-project/attachments/20120508/e8f963f5/attachment-0001.html>