From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kelly Dean Newsgroups: gmane.emacs.devel Subject: Re: Correspondence between web-pages and Info-pages Date: Fri, 02 Jan 2015 19:08:06 +0000 Message-ID: <5FQ2dQBTuvmn9epBBJwjkqA1D9qGmfVNRcstoLb4rYx@local> References: <81A0F722-D302-4298-B506-55A3FA8DC44B@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1420225751 8481 80.91.229.3 (2 Jan 2015 19:09:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Jan 2015 19:09:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 02 20:09:03 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y77am-0006Z6-7U for ged-emacs-devel@m.gmane.org; Fri, 02 Jan 2015 20:09:00 +0100 Original-Received: from localhost ([::1]:52352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y77al-0002u5-FO for ged-emacs-devel@m.gmane.org; Fri, 02 Jan 2015 14:08:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y77ai-0002q6-1O for emacs-devel@gnu.org; Fri, 02 Jan 2015 14:08:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y77ae-0007f6-Po for emacs-devel@gnu.org; Fri, 02 Jan 2015 14:08:55 -0500 Original-Received: from relay6-d.mail.gandi.net ([2001:4b98:c:538::198]:52568) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y77ae-0007cg-G5 for emacs-devel@gnu.org; Fri, 02 Jan 2015 14:08:52 -0500 Original-Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 7C4E3FB887; Fri, 2 Jan 2015 20:08:51 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 4hw4lOdmCcAU; Fri, 2 Jan 2015 20:08:50 +0100 (CET) X-Originating-IP: 162.248.99.114 Original-Received: from localhost (114-99-248-162-static.reverse.queryfoundry.net [162.248.99.114]) (Authenticated sender: kelly@prtime.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id DD031FB881; Fri, 2 Jan 2015 20:08:48 +0100 (CET) In-Reply-To: <81A0F722-D302-4298-B506-55A3FA8DC44B@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4b98:c:538::198 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:180926 Archived-At: chad wrote: > If the info browser is re-parsing the URL anyway, whats the value > added by forcing any change into the web server at all? Suppose Emacs gets an integrated browser, that displays both HTML pages a= nd Info pages. Like Firefox is an integrated browser for HTML and PDF. In= the latter case, if some document is available in both versions, you can= often pick which one you want by just swapping =E2=8C=9C.html=E2=8C=9D v= s. =E2=8C=9C.pdf=E2=8C=9D at the end of the URL. If both the HTML and PDF= versions of a page were named =E2=8C=9Cfoo=E2=8C=9D (or even worse, both= were named =E2=8C=9Cfoo.html=E2=8C=9D), how would you pick which one to = request from the server? Would you have the web browser send a different = request header, so that the name of the PDF version is =E2=8C=9Cfoo=E2=8C= =9D plus that header? That's the bad idea I argued against in my original= message. One of the desired features that other people have already expressed in t= his thread is for Info files to be available on the web, and enable the I= nfo browser to automatically download files that it doesn't already have = cached when you try to open URLs for Info pages that are in those files. = So having a single name that resolves to an HTML page online in a web bro= wser, but to an Info page offline in an Info browser, doesn't work. The I= nfo browser has to work online, and it's logical to integrate it with the= web browser, which means there must be a way to specify Info vs. HTML fo= r the page you want. And you specify what you want by using the name of i= t. That name should be a URL, not a URL plus something else. And the only change =E2=80=9Fforced into the web server=E2=80=9D is to ha= ve the name =E2=8C=9Cfoo=E2=8C=9D resolve to a redirect page (which is al= ready a standard feature available in web server software), so that names= are just URLs, and clients, not servers, choose whether to redirect to f= oo.html (specified by the Location header, compatible with standard web b= rowsers) or to the Info file specified by the Info-file header (which Ema= cs's Info browser will understand). An HTML-Info-integrated browser in Em= acs will understand both, so it can offer the user a choice. If you prefe= r Info, and people send you post-redirect names to HTML, you can tell Inf= o to automatically chop off the =E2=8C=9C.html=E2=8C=9D extension. If you= prefer HTML, no change is necessary. When you send people names, you or = they can chop off the =E2=8C=9C.html=E2=8C=9D. The name with no extension= is simply a way to automatically give people a link to both formats of t= he page, not just to one or the other. The value added is: There's a single name that points to both the Info and HTML pages, as Ste= fan wants. The choice is made by the client, as explained above and in my original m= essage. The design enables clean integration of the HTML browser and the Info bro= wser in the future.