Re: Beagle handling of compressed files and man pages

[Jon Trowbridge <trow ximian com>]

On Mon, 2004-06-07 at 21:45 +0200, Michael Levy wrote:
> how to "encode" an entry name in a URI or path.
> If we are passing paths around then we need a way to identify the
> specific entry of a multi-file archive....I may just be showing my
> ignorance, but I don't know how to do this. Any ideas? For Gzip and Bzip
> the point is moot (I think), but for Zip and Tar we'll probably want
> something. If any one has ideas, I'd gladly remove PeekablStream.cs and
> change IndexableCompressedFile. (would something like
> "file:///path/to/file.gz?entry=entry/path/and/file/name" do the trick in
> your opinion ?)

Your guess is as good as mine.  I think that using a file:// Uri for
(non-archive) gzipped and bzipped files is fine.  For zip and tar, what
you propose seems very reasonable but they probably shouldn't start with
file://.  Maybe:

tar://path/to/tarball.tar?entry=blah/blah/blah
zip://path/to/zipfile.zip?entry=blah/blah/blah

We'll probably want to special-case compressed archives, and assume that
any code that handles tar:// Uris will know how to handle

tar://path/to/compressed/tarball.tar.gz?entry=blah/blah/blah

> > In my tests, Gnome-vfs says that compressed man pages are of type
> > application/x-troff, not application/x-troff-man....
> > It might make sense to instead just have
> > a general troff filter that was optimized for the case of man pages.
> >
> I don't speak troff (or man for that matter) ;) 

Why don't we do the following: let's just declare your man-page filter
to be a generic troff filter and have it register as supporting
application/x-troff as well as application/x-troff-man.  Then we don't
have to spend any time tinkering with the mime type discovery.  We'll
let someone who actually has an archive of troff documents they care
about file a bug if the filter does the wrong thing with non-manpage
troff.

-J