Re: Generalising inlined images

Gisle.Aas@nr.no
X-Delivered: at request of secret on dxcern.cern.ch
Date: Thu, 7 Oct 93 08:21:53 +0100
From: Gisle.Aas@nr.no
Message-id: <9310070721.AA17252@nora.nr.no>
To: sanders@bsdi.com
Cc: www-talk@nxoc01.cern.ch
Subject: Re: Generalising inlined images
In-reply-to: <9310061941.AA04259@austin.BSDI.COM>
References: <9310061941.AA04259@austin.BSDI.COM>
Reply-To: Gisle.Aas@nr.no

sanders@bsdi.com writes:
> > My other problem with <IMG SRC...> and <INC SRV...> is that they do
> > different things depending on whether you're fetching via an HTTP server or
> > a client. I don't have any easy answers right now, but I forsee major user
> > confusion when people put together documents and test them locally, only to
> > find out they don't work off a server because of access privs. relative
> > pathing, etc. Any ideas?
> I think hacking <INC> into the server is a bad idea.  I've mentioned this
> before.  If you do that then you have really created a new type and it
> should be filename.hacked-html  instead of filename.html to make it
> clear that it's not HTML.  Then format negotiation would convert
> text/x-hacked-html to text/html if required (and when browsers start
> support <INC> They will just Accept: text/x-hacked-html).

I use this code with my plexus server (it does the work for me):
--------------------------------------------------------------------------

package inc;

sub init
{
    $main'ext{'hacked-html'} = 'text/hacked-html';
    $main'trans{'text/hacked-html'} = "text/html:inc'html";
}

sub html
{
    # this is a translation filter
    while (<STDIN>) {
	s/<inc\s+([^>]*)>/&inc($1)/ige;
	print;
    }
}

sub inc
{
    local($_) = $_[0];
    return scalar(`$1`)                      if /^cmd="([^"]+)"/i;
    return "<pre>\n".scalar(`$1`)."</pre>\n" if /^precmd="([^"]+)"/i;
    return eval "$1"                         if /^perl="([^"]+)"/i;
    return scalar(`cat $1`)                  if /^file="([^"]+)"/i;
    return "<em>&lt;inc $1&gt; not understood</em>";
}
1;