The handeling of urls and http/ftp/etc. protocols
should be simplified. This should fix bugs.
With regards to http urls xdvik should send a request
to the server to establish the mime-type the server
thinks the document is. If text/html, text/plain or
application/binary (common default types) is reported
back xdvik's own mime-type heuristics should be
applied. If any other type is reported xdvik should
heed it.
Xdvi should handle application/x-dvi and
application/dvi itself and hand all other types to the
assigned web browser.
Special needs in heuristics: Historicaly xdvi has had
two features people often use:
- Not having to type the .dvi extention, i.g., go 'xdvi
foo' to view foo.dvi
- Not having to use any specific filename extention on
dvi files: "xdvi foo" should pick up "foo" if it exists
This has two results:
- Filename search heuristics: foo, then foo.dvi
- xdvi's own mime-type heuristics must default to
application/dvi.
Logged In: YES
user_id=177175
See also bug #464922:
http://sourceforge.net/tracker/index.php?func=detail&aid=464922&group_id=23164&atid=377580
Logged In: YES
user_id=177175
Actually I'm starting to think that the entire www fetching
by xdvik is misguided from the start. Why not just invoke a
browser to fetch remote files? There are so many things
broken or missing in the browsing code ... some random
examples:
- You can't interrupt fetching a file. I've managed to get
status messages about a download into the statusline; next
I wanted to implement a `stop' button for the Motif
version. I wasn't able to find a libwww routine that
allows for that. E.g. when I kill my modem connection
while doing a download, xdvik will simply hang (I didn't
wait to find out how long it would take; it was more than
10 seconds). At that point I had to ask myself: Most
browsers have a stop button integrated in the GUI, so why
on earth do I need to we re-invent that wheel?
- No handling of username/password for protected http and
ftp sites. Libwww allows reading an ftp password, but we
don't have GUI elements for that. A simple solution
would conflict with the simple solution for the item
above, namely forking another instance of xdvi to do the
downloading and prevent freezing of the current instance;
the forked instance can't ask for a password any more.
- click on Thomas Esser's name in the title of TETEXDOC.dvi,
and you'll get a popup:
Couldn't open URL `mailto:te@informatik.uni-hannover.de':
libwww: Fatal Error: Wrong or unknown access scheme
(mailto)
Of course, mailto is a no-brainer for browsers. I haven't
even tried other schemes like https etc.
- libwww is a buggy monster, and the maintainers don't
respond to bug reports, so getting rid of it certainly
wouldn't hurt either.
I'll admit that having your own WWW fetching routines was a
neat and geekish thing in the 90s, but I really don't see
the point at present ;-) E.g. kdvi will (of course) use the
browser to fetch remote documents.
So, to sum up: I vote for disabling the www fetching stuff
altogether. It seems an easy way to do this is just to
return -1 at the start of fetch_relative_url as a first
step. Then we can wait if people complain, and if they
don't, progressively remove the underlying cruft.
If nobody has strong arguments against this, I'll go ahead
and do this first step in the next release of the HEAD
branch (if there ever will be one, that is - still haven't
gotten around to implement the hyperref fixes yet.)
Logged In: YES
user_id=177175
Just another remark on the file heuristics ... you wrote:
> - Not having to type the .dvi extention, i.g., go 'xdvi
> foo' to view foo.dvi
I agree with that ...
> - Not having to use any specific filename extention on
> dvi files: "xdvi foo" should pick up "foo" if it exists
... but I don't agree on this one. `foo' shouldn't really be
treated as a DVI file if no foo.dvi exists (I don't know of
any DVI creator that doesn't use the .dvi extension). I
think this is really part of the confusion about local and
remote files: For local files, having `foo' default to
`foo.dvi' (if such a file exists) makes perfect sense. But
for remote files, we can of course never know whether
`foo.dvi' exists. For these files, defaulting to
application/x-dvi is a major problem since it prevents a
reasonable treatment of a lot of URLs. The `mailto:' case is
an example for this: figure_mime_type will return
`application/x-dvi' for
`mailto:te@informatik.uni-hannover.de', which just doesn't
make sense. Similar for README files etc. Passing these
things to a browser would be give much better results ;-)
So in my view a reasonable heuristics would be:
- for ordinary filenames, or `file:' schemes, if filename is
`foo' or `foo.dvi': Check whether foo.dvi exists; if so,
pass to xdvi, else pass to browser.
- in all other cases, pass to browser.
Logged In: YES
user_id=177175
FWIW, rev. 1.49 of hypertex.c contains changes that
implement the suggestions from above.