From: gopher-project-bounces+rachael=telefisk.org@lists.alioth.debian.org
       Date: Mon Jan 11 19:07:26 2010
       Subject: Re: [gopher] gopher++ (gopher1) protocol
       
       On 2010-01-11 15:49, Kacper Gutowski wrote:
       
       >> Yes, servers would be *a lot more* complicated. But clients would be
       >> simpler as they could count on the server to do what's being asked.
       >
       > In order to support your Gopher++, clients would need to have
       > sophisticated detection and fallback routines because server is
       > free to fail some conversions even if it supports Gopher++.
       
       Well, everything falls back to gopher0. So basically, what you're saying 
       is that "rfc1436"-compliant gopher client needs sophisticated detection 
       and fallback routines - which incidently is true.
       
       [image transcoding]
       > I would choose to do a plain text. After all that's what is Gopher for.
       
       True. I got a bit carried away with stuff when I was writing it... I 
       think I should remove all traces of audio and video from the doc. Even 
       the image format conversions are a bit off - but definately useful as 
       images *are* important.
       
       > And if there are really such strict limitations I'd simply stick to
       > original Gopher protocol.  Mind that many would like to put their servers
       > on such limited devices.
       
       100% backward and forward compatibility. What's stopping you from using 
       a text-only gopher0 client? Why would you be bothered at the extra stuff 
       the server offers?
       
       >> do with text that has high-bit characters? Do you count on it being
       >> Latin-1 like the original RFC says? Do you trust it to be UTF-8? Do
       >> you try to magically sniff the content charset?
       >
       > I would be really happy to be able to just assume that's UTF-8.
       
       You can't, as gopher0 doesn't say it's UTF-8.
       
       > Server can not do much with non-Latin text when asked to serve it
       > as US-ASCII anyway.
       
       If I serve out standard Latin-1 menus my Firefox (both Win and Linux) 
       barfs and won't print those resource lines (don't know why). Stripping 
       the high-bit chars away at least lets me read most of the text. This 
       isn't some hypothetical thing either, this is what I encountered with my 
       UTF-8 filenames I was serving out.
       
       >> Seems pretty good to me.... If we take 1 server and 100 clients, I
       >> know where I would prefer my file format support to be - in the same
       >> place where the actual files are.
       >
       > That's a 1 server going out of resources pretty fast.
       
       That might be, but we don't know it until someone (me) tries it. But I 
       don't think the server runs out of resources - I'm not planning on doing 
       the conversions more than one (caching does exist).
       
       
       
       - Kim
       
       
       
       
       _______________________________________________
       Gopher-Project mailing list
       Gopher-Project@lists.alioth.debian.org
       http://lists.alioth.debian.org/mailman/listinfo/gopher-project
       Thread start
 (DIR) [gopher] gopher++ (gopher1) protocol
 (DIR) Followup: Re: [gopher] gopher++ (gopher1) protocol
 (DIR) Followup: Re: [gopher] gopher++ (gopher1) protocol
 (DIR) Followup: Re: [gopher] gopher++ (gopher1) protocol
 (DIR) Followup: Re: [gopher] gopher++ (gopher1) protocol
 (DIR) Followup: Re: [gopher] gopher++ (gopher1) protocol
 (DIR) Followup: Re: [gopher] gopher++ (gopher1) protocol