[prev in list] [next in list] [prev in thread] [next in thread] 

List:       konq-e
Subject:    Re: Announcement: MIME handling added + other changes
From:       Matthew Sheats <sheats () los-alamos ! net>
Date:       2002-07-03 18:37:34
[Download RAW message or body]


	Could someone point me to where these modifications exist in 
source?  Looking at the CVS tree for konq/e nothing seems to have changed 
in months.

	Thanks, Matt Sheats


On Wed, 26 Jun 2002, Paul Chitescu wrote:

> Hi!
> 
> In the last day have added a bunch of things to konq/e. Since the README
> file is almost empty this mail will document the new features until the
> documentation gets updated.
> 
> New configuration options:
> 
>     --enable-ftp  Compile in support for the FTP protocol - it is no longer
> in by default (adds about 50K of code);
>     --enable-cgi  Compile support for external protocol handlers (adds about
> 4K of code);
>     --enable-localbar  Make part of the toolbar disableable (by JS) or in
> launch panel;
>     --enable-launchpanel  Support for a special frame (named _launch_panel)
> to be used as launcher - key F2;
>     --enable-fontsubs  Support for Qt font name substitution when not
> provided by some other environment.
> 
> Protocol handlers:
> 
> [Local Protocols]
> name1=/full-directory-path
> name2=*/full-directory-path
> name3=!/full-path-to-executable
> ...
> 
> The first form just prepends the path to the URL path and tries to retrive
> the file exactly as the file: protocol.
> 
> The second form does the same but for executable files it executes them and
> returns the generated output.
> 
> The third form runs the executable no matter what the URL is, allowing it to
> perform any operations.
> 
> The environment variables are set as follows:
> GATEWAY_INTERFACE=LOCAL-CGI/1.1
> PROTOCOL_NAME=name-of-protocol
> SCRIPT_NAME=/path-of-executable-relative-to-protocol-base
> SCRIPT_FILENAME=/full-path-of-executable
> REQUEST_METHOD=GET
> REQUEST_URI=original-URI
> 
> SERVER_NAME=server-name-if-provided
> SERVER_PORT=server-port-if-provided
> QUERY_STRING=query-string-if-provided
> PROTOCOL_USER_NAME=unencoded-user-name-if-provided
> PROTOCOL_USER_PASS=unencoded-password-if-provided
> PROTOCOL_REFERER=referrer-url-if-available
> 
> Before execution the working directory is changed to the directory of the
> executable (so you don't need absolute paths for data files). No parameters
> are sent on the command line. stderr and stdin are not redirected, only
> stdout.
> 
> Note that no headers (not even MIME type) are processed! The output must
> contain only data.
> 
> [External Protocols]
> name1=command
> name2=@partial-url
> ...
> 
> The first form starts a /bin/sh -c with the full URL as argument. The
> working directory is NOT set. It does exactly like currently documented on
> the web page.
> 
> The second form performs a redirection, it prepends the partial URL to the
> specified one (with protocol: removed) and tries to go to that address.
> 
> Handling MIME types:
> 
> [MIME Handlers]
> type1,type2,...,typeN=-
> type,...=@type-alias
> type,...=|new-type|/full-path-to-filter
> type,...=/full-path-to-executable
> type,...=*/full-path-to-executable
> ...
> 
> The first form (-) marks the MIME type as invalid.
> 
> The second form (@) perform aliasing, the data is interpreted as being of
> type type-alias. Think of it as a null (type change only) filter.
> 
> The third form (|...|) sets up a data filter. The incoming data is piped
> trough the external filter and later interpreted according to new-type.
> 
> The last two forms execute a /bin/sh -c with the URL as argument. The
> working directory is NOT set. The version with (*) does not disconnect from
> server but instead tries to pipe the incoming data to the application trough
> stdin.
> 
> You can set a handler to multiple protocols, add them separated by commas.
> Incoming types are matched in the following order: type/subtype, type/*,
> */subtype, */*
> 
> Data path is as follows:
> protocol -> [filter|alias] -> {executable|browser}
> 
> While it's possible to add code to chain filters this is not currently
> implemented.
> 
> Font substitution:
> 
> [Font Substitutions]
> name1=replacement1
> name2=replacement2
> ...
> 
> 
> Examples:
> 
> [Local Protocols]
> short=/usr/local/konqe/shortcuts
> about=*/usr/local/konqe/about
> cgi=*/usr/local/konqe/cgi-bin
> mailbox=!/usr/local/konqe/mailbox-convert.cgi
> 
> [External Protocols]
> exec=/usr/local/konqe/exe-wrapper
> mailto=@file:/usr/local/konqe/mail-form.html?from=
> gg=@http://www.google.com/search?q=
> 
> [MIME Handlers]
> text/plain,text/source-code=|text/html|/usr/local/konqe/text2html.sh
> application/gzip=|text/html|/bin/zcat
> text/xhtml,text/x-html=@text/html
> application/mp3=@audio/mpeg
> application/octet-stream=/usr/local/konqe/wget-wrapper
> application/*,video/*=-
> audio/mpeg,audio/mp3,audio/x-mp3=*/usr/local/konqe/madplay-wrapper.sh
> 
> [Font Substitutions]
> arial=Caliban
> courier=Monospace
> 
> 
> WARNING!!!
> The data filter and execution with pipe are implemented using non-blocking
> IO in the same thread as the UI and are not quite stable. I just didn't want
> to create yet another job type and thread. Please experiment with the
> applications you intend to use this way. There should be no problem if these
> can consume the data fast enough but applications like audio/video players
> will cause trouble.
> 
> Needless to say that thorough testing is required. Try to build with
> combinations of configuration options. If enabled, see how CGI, filtering
> and piped execution work.
> 
> 
> Regards,
> 
> Paul
> 
> --
>  Paul Chitescu
>  pchitescu@null.ro   http://pchitescu.null.ro/   ICQ:22641673
>  Any spammers will be painfully squeezed into /dev/null
> 
> 
> _______________________________________________
> konq-e mailing list
> konq-e@mail.kde.org
> http://mail.kde.org/mailman/listinfo/konq-e
> 
> 

_______________________________________________
konq-e mailing list
konq-e@mail.kde.org
http://mail.kde.org/mailman/listinfo/konq-e
[prev in list] [next in list] [prev in thread] [next in thread]