Re: Beagle handling of compressed files and man pages

[Jon Trowbridge <trow ximian com>]

On Fri, 2004-06-11 at 10:43 +0100, Edd Dumbill wrote:
> In general, proliferating URI schemes is a bit excessive,

In general, I agree.  But in this case, I disagree. :)

> and seems
> troublesome adding one for each compression method you come across.

The set of compression/archiving schemes we need to support is pretty
small: tar, zip, gz.  Maybe one or two more.

> What you're saying is that a tarball or zip file can be a folder.  Why
> bother the user with implementation detail?

These URIs should not be exposed to users.  They should only be "seen"
by apps built on top of Beagle.  The hacky URI schemes are thus mostly a
programmer convenience and a mechanism for us to know how to just
transparently do the right thing.

The problem is that since tarballs, etc. are not actually folders, this
is much more than just an implementation detail --- doing what you
propose would make handling file: URIs substantially more complex, since
the only way to distinguish between

file:///path/to/folder.with.extension.tar/blah/blah/blah

and

file:///path/to/actual.tarball.tar/blah/blah/blah

is to walk up the path, checking each piece.  Basic operations like
checking if a file: URI is valid suddenly become much more complicated
(and expensive and error-prone), and the core file:-handling code needs
to be hacked every time a new archive or compression scheme is added.
Special URIs avoid all of that extra logic and computation and also
allows the URI handling to be done properly with plug-ins, which in the
end lowers the cost/complexity of supporting new archive types.

-J