Received: with LISTAR (v1.0.0; list gopher); Fri, 15 Jun 2001 09:34:38 -0500 (EST) Return-Path: Delivered-To: gopher@complete.org Received: from stockholm.ptloma.edu (stockholm.ptloma.edu [199.106.86.50]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 525D13B80B for ; Fri, 15 Jun 2001 09:34:38 -0500 (EST) Received: (from spectre@localhost) by stockholm.ptloma.edu (8.9.1/8.9.1) id HAA12236 for gopher@complete.org; Fri, 15 Jun 2001 07:37:50 -0700 From: Cameron Kaiser Message-Id: <200106151437.HAA12236@stockholm.ptloma.edu> Subject: [gopher] Re: Getting file info from an URI?? In-Reply-To: <3B29D81F.654F3EA9@si.hhs.nl> from 98002519 at "Jun 15, 1 11:40:47 am" To: gopher@complete.org Date: Fri, 15 Jun 2001 07:37:50 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 176 X-listar-version: Listar v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: spectre@stockholm.ptloma.edu Precedence: bulk Reply-to: gopher@complete.org List-help: List-unsubscribe: List-software: Listar version 1.0.0 X-List-ID: Gopher List-subscribe: List-owner: List-post: List-archive: X-list: gopher > Now the Gopher standard writes: "[t]he selector string should mean > nothing to the client software; it should never be modified by the > client." Now this implies three things: first, one _cannot_ determine a > file type by looking at the format of an URI. Well, this isn't *really* true. The first character is always the item type. Some gophers like URLs in this form gopher://x.y.invalid/11/something and others (like Bucktooth) don't need it twice, gopher://bucktooth.y.invalid/1/something but you can always make some guesses from that leading first character and except for the I item type which is usually but not always image/jpeg most of the others match up fine with a single MIME type. In fact, in the gopher browser I'm working on for the C64, it turns item types back into MIME types internally so the same handlers can do the same operations. > Second, one _cannot_ > assume that a Gopher selector is seperated by slashes. True; a Mac HFS gopher server, of which there are some, uses ":". > And third, even > if one could do just that, one _cannot_ assume that a "parent directory" > lists the child. Probably not. > 1) Use the Gopher+ "!" (information) selector feature > Problem: requires Gopher+. Can one assume Gopher+ nowadays? > Or are there still many "non-plus" Gopher servers around? > Please comment on this. No, there are many "G-" servers, including mine. -- ----------------------------- personal page: http://www.armory.com/~spectre/ -- Cameron Kaiser, Point Loma Nazarene University * ckaiser@stockholm.ptloma.edu -- Why, I'd horsewhip you if I had a horse! -- Groucho Marx -------------------