1) use a tmp directory /tmp/dillo-zxqw34/file_with_original_name_and.ext 2) The temp file is not needed for local files(file://). About memory and performance: If the mime support is in dillo the size of the code is in memory all the time, substracting memory size to the program launched to view the file and other programs. If it is a filter DPI it only uses mem before launch the program. It can use exec to not use mem after launch the program or other ways. More about avoid temp files for local files Dillo send a dpi command to the DPI with a url of the file. For example: <dpi command='open_file?' url='protocol://path/file.ext' content-type='if dillo know it'> The DPI pass the /path/file.ext to program if the file is local or download it and pass the /tmp/dillo-zxqw34/file.ext file to the program. The mime DPI can, and surely need to, do protocol handling too. Diego Sáenz / Darkspirit El Tue, 5 Jul 2005 12:29:37 +0200 Michael Kropfberger <michael@kropfberger.com> escribio: ...
I'm also voting for having external mime support directly in dillo. if there is a coordinated work is done, there is one prob with the avail external patch: even when passed though the file.dpi (eg. file://myacro.pdf) a new temp file is created and the external mime-viewer is called on this. there are several problems: 1) temp files are called eg. /tmp/dilozxqw34, so the extension is lost, which is problematic to some external programs 2) this creation of an extra copy temp file makes it unusable on handhelds, either memory- and performace-wise
just my 2 cents,
Mike