<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 23, 2015 at 5:15 PM, Ciprian Dorin Craciun <span dir="ltr"><<a href="mailto:ciprian.craciun@gmail.com" target="_blank">ciprian.craciun@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Compare this with Gopher which doesn't have any caching control<br>
mechanism, thus if I go between two menus (or files) back-and-forth,<br>
although their content didn't changed, they will get downloaded again<br>
and again.<br>
<br>
Therefore if we take into account the HTTP caching ability, Gopher<br>
loses quite badly.<br></blockquote><div><br></div><div>I kind of see Gopher a bit differently ;:)</div><div>Treat it as an "application protocol" if you will.</div><div><br></div><div>If you switch back and forth between menus...</div><div>Who's to say the content of those menus don't change each time? :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But on the bright side, I currently can see Gopher used perhaps in<br>
embedded software as a way to implement control dashboards or obtain<br>
debugging data.  This is due to the protocols simplicity, where there<br>
is no need for a Gopher client or server library, and one can use a<br>
straight socket and be fully up-and-running, thus perhaps implement<br>
something resembling a CGI solution in ten lines of Bash.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Precisely :)</div><div><br></div><div>cheers</div><div>James</div></div></div></div>