Re: [Nautilus-list] Tar content view



Hi Guys,

On Fri, 2002-01-25 at 18:04, Darin Adler wrote:
> The original design was that there's a module in gnome-vfs that knows how to
> interpret tar archives and make them seem like files to any program using
> gnome-vfs including Nautilus, using special URLs.

	Ok; so when I hacked around inside gnome-vfs trying to get compound
document support into shape I wrote some documentation on how 
the URLs worked in gnome-vfs/doc/uri.txt:

[snip]
 URI specification.

    This information was extracted from libgnomevfs/gnome-vfs-uri.c
which is the
authoratitive oracle for queries.

    A gnome-vfs URI can be assembled using the following method:

<method> :\ / <path> \ / End of URI
           X          X                  / <blank> - starts in root
directory
 <blank>  / \ <path> / \ '#' <method> ':'            or just pipes
through
                      ^                  \ <'/' path> -+- finish.
                      |                                |
                      +--------------------------------+

Examples:

	file:/home/michael/foo.txt  -  these open
	     /home/michael/foo.txt  -  the same file.
	
	ftp://ftp.gnome.org/pub/baa.txt.gz       -  this opens the raw gzip
data
	ftp://ftp.gnome.org/pub/baa.txt.gz#gzip: -  this opens the unzipped
data
 
	file:/home/rajit/efs.file#efs:/file
[snip]

	So on that basis I suppose you need to use:

	file:/foo/bar.tar.gz#gzip:#tar:/somewhere/afile.txt

	_But_ this never worked as far as I could see; and there are a number
of problems with this approach - mostly of managing the decompressed
data - with the separate gzip handler approach you really need to unzip
the whole stream before you can start doing an on-stream tar navigation
operation.

	Other problems would be that the VFS operates only within a single
process - and even then caching the data within a process is complicated
by the problems of someone opening readonly and then someone else
wanting it read-write [ quite apart from the issues of sanely writing
data into a tarred stream ].

	Then of course - there is cache lifecycle, tracking and cleanup, it's
not quite obvious how any uncompressed data should be cached, and for
how long, and if so who releases it, and what happens if the process
crashes in mid read of a 100Mb tar.gz :-) and who gets to clean the mess
etc. etc.

	So - the area is fraught with issue - but a simple tar file reader
component with a scad of limitations and inefficiencies is probably not
that hard - and better to have that than to be paralyzed by indecision
about the greater architectural issues :-) [ IMHO ].

> So the first part of this is to make sure that feature works, by finding out
> what the special URLs were supposed to be like, and then typing them into
> Nautilus and testing things like dragging files in and out of such windows.
> Then find and fix the bugs that prevent it from working nicely.

	Quite :-) To develop the gnome-vfs module, I would tend to use
gnome-vfs/tests/test-shell (since I wrote it :-) but it provides quite a
nice way to poke at your module in an intuitive style. ie. don't try to
debug nautilus and your new module at the same time :-)

	Anyway - hope that helps,

		Michael.


-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]