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