[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [gopher] Updated Gopher RFC



(sorry for double post)
        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    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 Damien Carol <damien.carol@gmail.com>
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:

> 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.

The good thing about mimetypes is that they're easier to expand without
breaking compatibility (although, given enough time, one can always
break anything).

> As ling as a client or whatever knows what it /can/ handle it can just
> ignore anything it doesn't recognise.

The key is to grow a set of itemtypes such that clients can readily
ignore everything else and just focus on what they can handle.


--
Nuno J. Silva (aka njsg)
gopher://sdf-eu.org/1/users/njsg
http://njsg.sdf-eu.org/

_______________________________________________
Gopher-Project mailing list
Gopher-Project@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@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project

Reply to: