Date: Sun, 14 Jan 2001 22:09:29 -0800
From: emanuel at heatdeath organisation <emanuel@heatdeath.org>
To: gopher@complete.org
Subject: [gopher] Re: Gopher "robots.txt"
Message-ID: <20010114220929.B885@success-info.com>
Mail-Followup-To: emanuel at heatdeath organisation <emanuel@heatdeath.org>,
	gopher@complete.org
References: <20010114211300.A885@success-info.com>
 <200101150532.VAA09174@stockholm.ptloma.edu> <20010115004043.A29080@mothra>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010115004043.A29080@mothra>;
 from s2mdalle@titan.vcu.edu on Mon, Jan 15, 2001 at 12:40:43AM -0500
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


On Mon, Jan 15, 2001 at 12:40:43AM -0500, David Allen wrote:
> Well if you're going to staple something new onto gopher, it makes
> sense to do it in gopher+, rathern than modifiying the original gopher
> with additions to it rather than gopher+, since after all gopher+ was
> just a set of modifications to gopher. :)
> 
> [...]
>
> Hm.  Well, I can agree with this, but at the same time, what is to
> become of gopher+?  You can either merge it with the original gopher
> and say "this is what gopher is, and we'll write software
> accordingly", or you can throw out gopher+ and stick only with gopher,
> but having gopher+ sitting around as something that might be supported
> and might not be seems like a pain.  Gopher+ has some decent
> abilities, and I don't see why you shouldn't use them in this
> situation.  So maybe we should be asking if gopher+ is something that
> should continue to be sometimes-supported, or if it should be taken in
> or thrown out.

Well said.  

I am firmly on the side that says we should use and support Gopher+ as
much as possible, and use it as the basis for any extra features,
because it was made with expandability in mind.  Gopher (non-+) does not
have this expandability, and I'm afraid that by stapling features onto
it we'll just get a huge mess.

AFAIK there is only active gopher robot out there, which is floodgap's
V2.  This is quite a nice situation to be in for doing things right.  If
we want to keep this good situation, a gopher robot library should be
created that any other robots would make use of, which encapsulates the
complexity of this stuff.

Also, I don't think it would be that difficult to add minimal Gopher+
support to a server, just enough to deliver basic attribute information
needed to support the robot.

Also putting the robots information in an empty i directory entry
worries me.  First off, clients may do wierd things with it.  In some,
it will not appear, but in others it'll be confusing for the user.  With
one such "pragma" it's okay (ane blank item at the end of the directory
is not a big problem), but what about the future?  Will we start adding
more of these?  It would be very strange to have ten blank directory
entries at the end of the screen.  These are precisely the kinds of
problems that Gopher+ was created to solve.  We should use it.

-- 
emanuel at heatdeath organisation
gopher.heatdeath.org