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 |
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:" |
> > 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 forWe sort of have that with I (sort of), and ; and s, and (less widely
> > 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".
accepted) d.
-- Everywhere is within walking distance if you have the time. ----------------
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@floodgap.com
_______________________________________________
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