On 2010-01-11 14:41, Mateusz Viste wrote:
I was going to address that packet loosing thing too. A TCP packet is generally at least 1K in size. Why would a gopher++ client purposefully split the selector and the first header line into two TCP packets?What do you know about that? Nothing. You don't control how the client will prepare his packets. What about clients with very small MTU?
A theoretical client which purposefully splits the first two lines into two different TCP packets splitting them EXACTLY after the first CRLF gracefully falls back to standard gopher0. That's about as clean fallback as there can be.
That breaks gopher0 which I was not willing to do. Extra lines don't.What about adding some more<tab> chars to the first line? Gopher0 servers read the selector until the first tab.
... and hand over the rest to a type 7 search script. A search query does not end at the second <tab>. Adding anything new to the selector basically breaks gopher0.
Why not adding yet another<tab>? This way, old gopher servers won't break. Just an idea.
And not a bad idea at all. I just thought I could do it without adding anything to the selector. Unfortunately I couldn't test it so it's all a bit hypothetical.
What's wrong with iconv(3)? Of course the server has to know the originating charset to do the conversion, but that's a _server_ problem,Okay. Let's say I have a file which contains the text "текстовый файл". Now, the client is asking for this file, expecting to get LATIN1 charset. What do you do?
How is this different from the problems we had for 30 years before UTF came around?
How do you solve thise using gopher0? You don't, because the only charset that works is 7bit US-ASCII. The rfc says you can use Latin-1 but that won't work either (at least my FF doesn't work with it for some reason). With gopher++ there's at least a chance that the client asks for UTF-8 which will support the russian charset.
Basically, gopher++ doesn't take away anything (since everything can fall back to gopher0), it only adds more possibilities.
- Kim _______________________________________________ Gopher-Project mailing list Gopher-Project@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/gopher-project