[gopher] gopher++ (gopher1) protocol

[Kacper Gutowski]

On 2010-01-11 21:56:00, Kim Holviala wrote:
> Yes, it exactly the same thing than views. Which is why I'm a bit
> baffled why views are a good thing and my transcoding isn't...

I think that protocol should not impose any restrictions on the type
of data.  I wouldn't put anything about actual formats in a protocol
specification except the way to negotiate the content because the
formats used may and will change sooner or later.  Speaking about
content negotiation - Gopher+ already has it.  However Gopher+
requires two-pass negotiation and I think that approach similar to
HTTP (as proposed here) might be more feasible.

However I think that since it would not be feasible to request that
server is strictly required to do some conversions on its own.
Now don't get this wrong.  Having multiple views or formats of
the same resource is a good idea and if you want you can provide those
dynamically by transcoding data upon client request.  But the protocol
itself should provide some higher abstraction of those.  Specification
should not care whether you manually put the files or do it in-the-fly.
Especially since now server doesn't have to know in advance what is
available (like the Gopher+ VIEWS that have to be advertised before
the actual request) but can check what is available after the request
is actually made.

> I didn't add to gopher+ because I admire the simplicity that is
> gopher0. I think that + was a bit rushed and kind of an ugly hack. I
> won't say mine is any better, though...

You might be right (I had the same feeling but after all it's not that
bad), but your proposal is definitely more "rushed" :)

-- 
Kacper Gutowski