Re: Browser suggestion: local server

Steve,

What you need is a WAMP (Windows) or LAMP (*nix) Stack.  These include a Server, Scripting and a Data Base integrated to the Local Host at IP 127.0.0.1.  They come in executable zip files.

Apache2 (can) will process Server Side Includes (*.shtml) by itself as an alternative to the Scripting (Perl, PHP, etc.).  This is a nice "feature" since using the script engine has a cost. The scripting is much more versatile than Server Side includes, and the reason UA vendors don't handle these is because one quickly needs more sophisticated tools.  Server Side includes are not used much because the code cannot be reused.  Of course it can be copied, and even inserted automatically, but write once, run often is not all that is meant by the term.

--Gannon
--------------------------------------------
On Sun, 11/29/15, Steve Comstock <steve@trainersfriend.com> wrote:

 Subject: Re: Browser suggestion: local server
 To: "Gannon Dick" <gannon_dick@yahoo.com>, "Ian Hickson" <ian@hixie.ch>, public-html-comments@w3.org, simonp@opera.com, markdavis@google.com, addison@inter-locale.com, team-liaisons@w3.org, "Ian Jacobs" <ij@w3.org>, "Ulrik Dobashi Hansen" <ulrik@808.dk>, "Bert Bos" <bert@w3.org>
 Date: Sunday, November 29, 2015, 7:18 AM
 
 Well, lots of suggestions
 on how to do this without
 changing the
 standards for UAs. And I researched
 and even
 tested several of these.
 
 But they miss the mark, in my opinion.
 
 
 The advantage
 in requiring UAs to handle SSI include
 statements if it is pointing to a local file is
 that
 I can have a portable site with no need
 to connect
 to the internet and no need to
 install supplemental
 software or write code
 that might not work on some
 other
 platform.
 
 If UAs did this,
 I can show my portable website no
 matter if
 the browser is IE, Chrome, Firefox, Opera,
 Safari, ... and no matter if the platform is
 Windows,
 Mac, Linux, ...
 
 So this enhancement would support: useability,
 flexibilty,
 portability.
 
 
 In the absence, I'll
 continue testing by loading up all
 my files
 to the server and then pointing to the starting
 page on the server.
 
 
 Thanks anyway folks.
 
 
 -Steve
 
 
 
 On
 11/28/2015 6:08 AM, Steve Comstock wrote:
 > On 11/12/2015 11:36 AM, Gannon Dick
 wrote:
 >> Hello Steve,
 >>
 >> There are
 excellent, not IT motivated reasons for
 >> using a local server, or better said
 locating an
 >> (actual) interface at
 127.0.0.1.
 >
 > Well,
 I'm aware of that interface, but it is not
 > at all what I'm talking about; my
 suggestion needs
 > code in the browser to
 simulate the way a server
 > handles
 <!--#include ... --> statements.
 >
 >
 >> This is not how the "Web of
 Things" works,
 >
 > but I don't care about that.
 >
 >> but this is how
 people arrange collections of
 >>
 reference documents.  This is highly significant
 >> in Emergency Management where hardware
 and
 >> connectivity can be disrupted
 by the event itself
 >> ... but you,
 your laptop and trusty thumb drive
 >>
 survived.  There are Portable Apps ...
 >> (http://portableapps.com/), but your
 trusty thumb
 >> drive might not have
 its favorite laptop around.
 >
 > My proposal has nothing to do with
 survival in an
 > emergency, it's far
 more prosaic. If I have all the
 > pages
 and files for a website on a thumb drive, then
 > any laptop will work because there will be
 some
 > browser on the laptop.
 >
 >
 >
 >
 >> You can count on at least a working
 browser on a
 >> working laptop, I
 think.
 >
 >
 > Me too.
 >
 >
 > So, if the browser
 supports the current standard,
 > and if
 the standard says when a browers is pointed
 > at a local file whose name ends in
 '.shtml' then
 > the browser
 should attempt to handle server side
 >
 includes in the same way a server does.
 >
 >>
 >> That said, the document collection
 should then be
 >> XML ... because the
 style, spin, persuasion,
 >>
 salesmanship whatever you want to call it that
 >> XHTML inherits from HTML should not
 distract or
 >> interfere with
 access.
 >
 >
 > Well, I don't want to step on any toes
 here, but
 > my impression is that XHTML
 is kinda' moribund and
 > that the
 latest HTML version is actually gaining
 >
 steam. Of course, I could be totally wrong (it
 > wouldn't be the first time).
 >
 > And, it shouldn't
 matter: if the HTML standard were
 > to
 support my suggestions, presumably that would
 > also be supported in XHTML.
 >
 >
 >>
 >> c.f.
 >> http://Stratml.us/
 >> http://www.rustprivacy.org/2015/stratml/cap_sml/vfsroot/
 >>
 >>
 >> --Gannon
 >>
 --------------------------------------------
 >> On Thu, 11/12/15, Steve Comstock
 <steve@trainersfriend.com>
 wrote:
 >>
 >>   Subject: Browser
 suggestion: local server
 >>   To: "Ian
 Hickson" <ian@hixie.ch>, public-html-comments@w3.org,
 >> annevk@opera.com, simonp@opera.com, markdavis@google.com,
 >> addison@inter-locale.com,
 team-liaisons@w3.org,
 "Ian Jacobs"
 >> <ij@w3.org>, "Mark
 Douglas (CITEC)" <Mark.Douglas@CITEC.COM.AU>,
 >> "Patrick Loftus" <patrick.loftus@TNT.COM>,
 "Ulrik Dobashi Hansen"
 >>
 <ulrik@808.dk>,
 "Bert Bos" <bert@w3.org>
 >>   Date: Thursday, November
 12, 2015, 11:08 AM
 >>
 >>   Guys,
 >>
 >>   I've been doing a lot
 of development using .shtml
 >>   and server side includes.
 Testing, however, is a
 >>   bit of a pain: I
 can't really test the includes
 >>   are working until I
 upload all the files to my
 >>   server.
 >>
 >>   It occurs to me it would
 be terrific if this
 >>   could be part of some
 standard:
 >>
 >>   * If a browser (user
 agent) points to a local file,
 >> 
    and if the filename ends in '.shtml',
 then the
 >>     browser
 should endeavor to process any 'include'
 >>     statements in the file
 in the same way a server
 >> 
    would
 >>
 >>
 >>   This would also be nice
 because I can put a whole
 >>   website on a thumb drive
 then display it to a meeting
 >>   or class without having
 to actually connect to the
 >>   internet! Makes the site
 much more portable.
 >>
 >>   Is that reasonable?
 Desirable? How do I go about
 >>   proposing such
 behavior?
 >>
 >>
 >>   Kind regards,
 >>
 >>
 >>   -Steve Comstock
 >>   303-355-2752
 >>
 >>
 >>
 >

Received on Monday, 30 November 2015 18:41:15 UTC