Re: [gopher] gopher++ (gopher1) protocol
Hello,
Kim Holviala wrote:
The server SHOULD be able to convert all audio resources to either WAV,
MP3 or OGG Vorbis. A client SHOULD not ask for any other format.
Gopher and the lossy audio codecs?
Such restrictions in the protocol are not future-proof.
My problems with Gopher are, that there is no way to get just
a chunk of a file and there is no way to determine out of the
selector string, if the request will return me a menu or a
file.
The gopherfs I've written a while back needed to download the
whole file to creating the required thumbnails for the file
managers. Another problem was, that you don't know, what you
will get back, when trying to get a selector.
A good Gopher alternative should be a simple single request
based protocol, which includes the hierarchy definition. All
that file type bloat could be left to a simple extension match-
ing or more magic, coming from file(1).
Of course, this will leave no backward compatibility, which
is the intention of an "alternative".
As an idea, there should be only two types in the protocol:
menu and file. The client can request a file or a menu and
the server has to follow. This would for example allow us
to send back the file size in this metadata, when you request
the "menu" of that file. By having such a feature, a file
system interpretation of the protocol could always determine,
if the selector is a file or a menu.
Sincerely,
Christoph
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/gopher-project
Reply to: