[gopher] Updated Gopher RFC

[Nick Matavka]

On 8 May 2012 12: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:"
>
> 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/
>
> _______________________________________________
> Gopher-Project mailing list
> Gopher-Project at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
>

Not trying to be an arse, but can you please not use rich text?  Some of us
use ReAlpine for our e-mail, just as some of us use Lynx for our browsing,
and having to see garbled rich text makes the experience... well, not fun
at all.  I think both of you are right, I think we should clarify, make
more rigorous, and clarify the definitions of the existing selectors, but I
also think that there should be some new selectors for formats that weren't
around in 1992.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gopher-project/attachments/20120519/dac2c592/attachment-0001.html>