From: gopher-project-bounces+rachael=telefisk.org@lists.alioth.debian.org
Date: Wed May 9 20:17:54 2012
Subject: Re: [gopher] Updated Gopher RFC
--===============2910879631439894631==
Content-Type: multipart/alternative; boundary=e89a8f3ba0e995117f04bf9e8369
--e89a8f3ba0e995117f04bf9e8369
Content-Type: text/plain; charset=UTF-8
That's my purpose, to keep existing item and add Generic one.
MIME types related things will NOT be adopted for the same reasons that
Gopher+ failed...
Just keep gopher simple PLZ
2012/5/9 John Goerzen <jgoerzen@complete.org>
> Just a couple of cents from someone that's been passively watching this
> discussion. Feel free to ignore me ;-)
>
> If we might use one word to describe Gopher, it is "simple." Gopher+
> somewhat violates this, and HTTP severely violates this. MIME types have
> their uses, and the Web and email wouldn't work so well without them.
> However, even after all these years, they still aren't dealt with quite
> right. If you click on a file on a Web server named foo.zip and the
> Content-Type header says it's image/gif, what happens? And what happens
> after you do File -> Save in your browser, then try to open it up later?
> (Note: these two things are not normally the same!)
>
> Proper mailcap and MIME type handling could of course be added to Gopher.
> But I would ask: why?
>
> I think instead of adding more types, we could remove types and simplify.
> The would be:
>
>
> - Plain text (ASCII or UTF-8)
> - Binary data
> - HTML text (ASCII or UTF-8)
> - gopher directory
> - info pseudo-type
> - Media
>
> The "media" type would simply be binary data with a hint to the UI to
> attempt to display it based on its extension.
>
> There are existing item types in existing specs that all of the above map
> to.
>
> Let the client use its own mailcap, or whatever, to decide what to do with
> media data.
>
> -- John
>
>
> _______________________________________________
> 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/
--e89a8f3ba0e995117f04bf9e8369
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
That's my purpose, to keep existing item and add Generic one.<br><br>MI=
ME types related things will NOT be adopted for the same reasons that Gophe=
r+ failed...<br><br>Just keep gopher simple PLZ<br><br><div class=3D"gmail_=
quote">
2012/5/9 John Goerzen <span dir=3D"ltr"><<a href=3D"mailto:jgoerzen@comp=
lete.org" target=3D"_blank">jgoerzen@complete.org</a>></span><br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Just a couple of cents from someone that's been passively watching
this discussion.=C2=A0 Feel free to ignore me ;-)<br>
<br>
If we might use one word to describe Gopher, it is "simple."=
=C2=A0
Gopher+ somewhat violates this, and HTTP severely violates this.=C2=A0
MIME types have their uses, and the Web and email wouldn't work so
well without them.=C2=A0 However, even after all these years, they stil=
l
aren't dealt with quite right.=C2=A0 If you click on a file on a We=
b
server named foo.zip and the Content-Type header says it's
image/gif, what happens?=C2=A0 And what happens after you do File ->
Save in your browser, then try to open it up later?=C2=A0 (Note: these
two things are not normally the same!)<br>
<br>
Proper mailcap and MIME type handling could of course be added to
Gopher.=C2=A0 But I would ask: why?<br>
<br>
I think instead of adding more types, we could remove types and
simplify.=C2=A0 The would be:<br>
<br>
<ul>
<li>Plain text (ASCII or UTF-8)</li>
<li>Binary data</li>
<li>HTML text (ASCII or UTF-8)</li>
<li>gopher directory</li>
<li>info pseudo-type<br>
</li>
<li>Media</li>
</ul>
The "media" type would simply be binary data with a hint to t=
he UI
to attempt to display it based on its extension.<br>
<br>
There are existing item types in existing specs that all of the
above map to.<br>
<br>
Let the client use its own mailcap, or whatever, to decide what to
do with media data.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- John<br>
<br>
</font></span></div>
<br>_______________________________________________<br>
Gopher-Project mailing list<br>
<a href=3D"mailto:Gopher-Project@lists.alioth.debian.org">Gopher-Project@li=
sts.alioth.debian.org</a><br>
<a href=3D"http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-p=
roject" target=3D"_blank">http://lists.alioth.debian.org/cgi-bin/mailman/li=
stinfo/gopher-project</a><br></blockquote></div><br><br clear=3D"all"><br>-=
- <br>
Damien CAROL<br>
<a href=3D"gopher://dams.zapto.org/1/" target=3D"_blank">gopher://dams.zapt=
o.org/1/</a><br>
--e89a8f3ba0e995117f04bf9e8369--
--===============2910879631439894631==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
--===============2910879631439894631==--
Thread start
(DIR) [gopher] Updated Gopher RFC
(DIR) Followup: Re: [gopher] Updated Gopher RFC
(DIR) Followup: Re: [gopher] Updated Gopher RFC
(DIR) Followup: Re: [gopher] Updated Gopher RFC
(DIR) Followup: Re: [gopher] Updated Gopher RFC