zap wrote:
Would a gopher server be out of the question for the Commodore 64. ?
Not at all - I'm currently working on a combined gopher/http server (listens on a single port, if the request starts with a GET it assumes http, otherwise it assumes gopher).
The big design question I have is how to provide the content to be served. Current thinking is to serve files off drive #8. Files will be treated as follows:
1) PRG files are treated as binary (no conversion applied, type '9' for gopher, 'application/octet-stream' for http) - no conversion applied.
2) SEQ files that end with ".htm" will be served as html (type 'h' for gopher, 'text/html' for http) - petscii-ascii conversion applied as it is sent over the network
3) SEQ files that don't end with ".htm" will be served as text (type '0' for gopher, 'text/plain' for http) - petscii-ascii conversion applied as it is sent over the network
Since the gopher browser doesn't understand html or allow d/l of binary files, only the last file type will be usable to the c64 gopher browser.
If there is a file called "index.htm", it will be served as the root document for http requests.
If there is a file called "index.gopher", it will be served as the root document for gopher requests.
If no root document is specified, an index of all the SEQ/PRG files in drive #8 will be created and served instead.
All disk access will be via standard kernal calls (i.e. no fastloader, although should work with JiffyDos I believe)
Anyone got any feedback on the above approach?
zap wrote:
any chance of allowing use of static ip's.
Yes