It's my proposal : to have generic types :
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:"
2012/5/8 Nuno J. Silva <nunojsilva@ist.utl.pt>On 2012-05-08, Alistair wrote:The good thing about mimetypes is that they're easier to expand without
> On 08/05/2012 17:01, zack mayson wrote:
>> Gopher is generally designed to be a low overhead protocol; plus, it
>> would introduce incompatibilities in clients running on old computers
>> (i.e. Zilogs, Sinclairs) and specifying what kind of data/files/content
>> X is neans a lot less work for client Y.
>>
>
> Trouble is there's a gazillion kinds of file and soon you end up with
> a huge mess like mimetypes.
breaking compatibility (although, given enough time, one can always
break anything).
The key is to grow a set of itemtypes such that clients can readily
> As ling as a client or whatever knows what it /can/ handle it can just
> ignore anything it doesn't recognise.
ignore everything else and just focus on what they can handle.
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
_______________________________________________ Gopher-Project mailing list Gopher-Project@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project