Received: with ECARTIS (v1.0.0; list gopher); Tue, 17 Sep 2002 16:01:43 -0500 (EST) Return-Path: <wzk@happy-ent.de> Delivered-To: gopher@complete.org Received: from um1b.pce.de (um1b.pce.de [213.185.64.7]) by gesundheit.complete.org (Postfix) with ESMTP id 3305F644DD for <gopher@complete.org>; Tue, 17 Sep 2002 16:01:41 -0500 (EST) Received: from win98.happy-ent.de (ppp-huerth-45.pce-net-line.de [213.185.65.173]) by um1b.pce.de (8.9.3/8.9.3) with ESMTP id XAA19037 for <gopher@complete.org>; Tue, 17 Sep 2002 23:01:29 +0200 Message-Id: <5.1.0.14.1.20020917223031.00a09830@um1b.pce.de> X-Sender: qe-wzk@um1b.pce.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 17 Sep 2002 23:10:46 +0200 To: gopher@complete.org From: Wolfgang Zekoll <wzk@happy-ent.de> Subject: [gopher] Re: Encouraging MIME types In-Reply-To: <200209162155.58117.hardburn@runbox.com> References: <20020916023229.GB25785@complete.org> <200209142214.35897.hardburn@runbox.com> <20020916023229.GB25785@complete.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 696 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: wzk@happy-ent.de Precedence: bulk Reply-to: gopher@complete.org List-help: <mailto:ecartis@complete.org?Subject=help> List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe> List-software: Ecartis version 1.0.0 List-ID: Gopher <gopher.complete.org> X-List-ID: Gopher <gopher.complete.org> List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe> List-owner: <mailto:jgoerzen@complete.org> List-post: <mailto:gopher@complete.org> List-archive: <http://www.complete.org/mailinglists/archives/> X-list: gopher

I would neither stop gopher0 extension nor drop gopher0 (in parts or complete) to go for gopher+.

Why? I expect running and maintaining a gopher0 server is simpler than doing the same with a gopher+ server and gopher+ features.

But this is only on side. Programming a gopher0 client or server is also simplier than going directly for gopher+. So if someone would come up with nice ideas and/or features for gopher0, perhaps with demand for new gopher0 types he would most probably get my full support (working with new gopher0 types is what I do sometimes in my client).

To the current question regarding the m-type and the use of MIME-types: I don't have nothing against it but I also do not see the feature, I don't know why I should really care about it.

One additional thing: going for gopher+. As I understand gopher+ it's not the solution, it's a framework for extensions. The suggested MIME types are no problem with gopher+, the real question is the 'how'? gopher+ defines only the format of gopher+ blocks but not their content and not their interpretation. gopher+ features can be only put into a client if there's is at least one server (read 'server software') that supports them. But on the other side you need clients. And here I come back to the above: Looking if a feature is working, developing a gopher client is easier for gopher0.

At the end I have a question: what is our (or your personal vision) for a native gopher client (either 0 or +)?

For my own gopher client project it's first to have a program that works as a directory browser in today's Internet with integration for external programs (see latest release). But this is something I'm still working on (by the way, the next step for this will implement a new gopher0 type for external links).

After that I plan to think about turning gopher into a simple ASCII dialog system (edit the current text file, then send it back to the server).

Just my personal opinion.

Regards,

Wolfgang Zekoll