[gopher] Re: meta: item types, etc.

[Roman Pavlov <webmaster@xxxxxxxxxx>]

Some existing gopher servers can be easily ported to windows using=20
cygwin. Bucktooth runs on Cygwin. I suppose Pygopherd also should, and=20
it has +VIEWS support. Due to the architecture of Python, I suppose it=20
can be easily ported to native Windows. Even UMN gopherd can be compiled=20
after some hacking (I didn't finish it, but hope to do this some day).=20
However, I was talking not about implementing whole gopher+ but only its=20
VIEWS syntax.

Gopher+ was fully implemented in UMN gopher server and client and=20
actually widely used before the decline of UMN gopherd, so we can hardly=20
consider it just a proposal (however not many servers, if any, actually=20
used gopher+ interactive features like ASK forms, so I agree that they=20
haven't proven to be quite practical).

JumpJet Mailbox wrote:
> There is only 1 Gopher Server program for Windows Platforms.=A0 It is
> NOT Gopher +.=A0 Once someone writes an alternative Windows Gopher
> Server that IS Gopher +, this might be a possiblility. =A0 Note:=A0
> Gopher + is=A0only a --PROPOSED-- extension to Gopher.=A0 It may NOT be
> the best proposal, especially when considering the cabalilities of
> modern personal computers. --- On Sat, 7/5/08, Roman Pavlov
> <webmaster@xxxxxxxxxx> wrote:
>=20
> From: Roman Pavlov <webmaster@xxxxxxxxxx> Subject: [gopher] Re: meta:
> item types, etc. To: gopher@xxxxxxxxxxxx Date: Saturday, July 5,
> 2008, 8:04 AM
>=20
> Maybe just using gopher+ VIEWS feature would help? Implementing just
> a subset of gopher+ in clients and servers shouldn't be very hard and
>  wouldn't probably cause much protest from gopher+ critics.
>=20
> Cameron Kaiser wrote:
>> I've been having back-channel discussions with gopher wranglers who
>>=20
> note that
>> the item types they have selected for their content, while working
>> in
> Mozilla
>> due to content sniffing, don't work in Overbite which rigidly
>> enforces
> its
>> particular internal set (all others being seen as
> application/octet-stream).
>> Although I made some token expansion with the p and d item types,
>> at some point there is going to need to be an expanded and
>> formalized item type
> and
>> MIME type mapping list maintained by a central authority or this
>> problem
> is
>> going to come up again. I think it is especially important now
>> given that there are others looking at creating their own
>> particular clients, since
> it
>> would be very confusing for users to have clashing item types
>> between
> apps.
>> This is something I don't mind being a point person and
>> clearinghouse
> for,
>> but that aside, a formalized process for this needs to be devised.
>>=20
>=20
>=20
>=20
>=20
>=20