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:" |
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