[gopher] RFC submission?

[James Mills]

On Sat, Jan 3, 2015 at 7:27 PM, Mateusz Viste <mateusz at viste.fr> wrote:

> On 01/03/2015 10:14 AM, Nuno Silva wrote:
>
>> a) We have no way to convert all the gopherspace to utf8, assuming utf8
>> in some clients will probably break compatibility with older gopherholes
>>
>
> That's why I suggested a CAPS capability for declaring server's encoding a
> few days ago. There is already a good number of gopherholes using utf8, so
> it's not really something 'new', but unfortunately gopher clients don't
> have much chance to identify the encoding used by a server (other than
> guessing).


I agree. If we can't/shouldn't change existing Gopher servers and clients
we *should* at least adopt a standard form in CAPS so existing clients
(optiona)
and newer clients can take advantage of this.

For instance my Gopher server (cgod) by default outputs UTF-8.


>
>
>  Just one image itemtype makes no sense, as there are different image
>> formats.
>>
>
> There are plenty of sound formats, too, and still, only one gopher type
> ('s'). I see the gopher types as a way of saying more or less what kind of
> media to expect (text, document, image, video....), not necessarily an
> indication of the exact file format. But anyway, we are talking here about
> two itemtypes for images ('g' and 'I'), I don't really think it's worth the
> trouble changing that. By now, everyone got used to this already.


I also agree. IHMO a "client" doesn't necessarily "render" the
content/resouce.
Usually some external program does. e.g: "open" on OS X.
or "display" (for images) on *NIX.

My point is that one can configure a Gopher client to open
*any* image with "display" and it doesn't matter type of
image that is.

cheers
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gopher-project/attachments/20150103/3e1bf003/attachment-0001.html>