Complete.Org: Mailing Lists: Archives: gopher: January 2006:
[gopher] Re: PyGopherd and Gopher+

[gopher] Re: PyGopherd and Gopher+

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] Re: PyGopherd and Gopher+
From: "R.A.Pavlov" <webmaster@xxxxxxxxxx>
Date: Mon, 2 Jan 2006 12:32:24 +0300
Reply-to: gopher@xxxxxxxxxxxx

By the way, I think a nice extension of basic gopher protocol is
implemented in GN gopher server - I have just installed it on local
machine yesterday, played with it for a while and have been very
satisfied - a compact ( about 50Kb binary) and fast server with all the
features of UMN gopherd (except gopher+) and a "gophery" way of adding
extended features - by adding some extra item types (transparently for
the client) - like 7g for embedded grep-like search, 1m for "structured
files" presented as directories (as mailbox files), 0h if a HTML version
of a file is provided (something like +VIEWS), 7w, 7wc, 7wh etc. 
for different types of wais
searches etc.

On Sun, Jan 01, 2006 at 09:24:54AM -0800, Cameron Kaiser wrote:
> >    I think gopher+ stinks anyway.  Instead of opening a new connection to  
> > fetch the new (mostly undefined) attributes it would have been easier to  
> > keep reserving extra tabspaces in the menus for simple things like  
> > mimetype and filesize.  My reason for not adding gopher+ to GopherJ is  
> > that it doesn't compliment the original protocol.  And as Mr. Goerzen  
> > said, it's not very gophery.
> I agree. I would have much preferred simply extending the tabspaces. Even
> ASK-type blocks could be emulated in some fashion with this.
> -- 
> --------------------------------- personal: 
> ---
>   Cameron Kaiser * Floodgap Systems * * ckaiser@xxxxxxxxxxxx
> -- Look busy. Jesus is coming soon. 
> -------------------------------------------

Yours, etc.
        Roman A. Pavlov


[Prev in Thread] Current Thread [Next in Thread]