[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 102265] nested kioslaves for archives
From:       Andy Koppe <andy.koppe () ed ! ac ! uk>
Date:       2005-03-25 9:22:02
Message-ID: 20050325092202.30080.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=102265         




------- Additional Comments From andy.koppe ed ac uk  2005-03-25 10:22 -------
When you say the second way is doable now, do you mean for 3.5? That would be great, \
in whatever form, especially if it gets discussions about ioslave architecture for \
4.0 going.

I also prefer the first scheme though, because it's cleaner and more readable.

The fish-inside-fish scenario would actually be quite useful, e.g. it would allow me \
to browse my computer at work while having to go through my department's ssh gateway, \
but it doesn't seem to fit the kind of URI nesting we're discussing here. 

But extending the fish URI scheme to support host chains might do the job. (Should I \
file a separate wish for that?)

  fish://user1 host1//user2 host2/dir/file

Apart from that, one could imagine ioslaves that support encrypted files or archives, \
thus requiring username or password.

If something like the multi: scheme could be done with URIs, then how about the \
scheme I had originally suggested? It doesn't necessarily have to use parentheses; \
perhaps square brackets or curly braces would be preferable, e.g.:

  tar:(file:/dir/archive.tar)/file
  gzip:[sftp://user host/dir/doc ps gz]
  bzip2:{tar:{fish://host/archive.tar}/file.bz2}

I think any of those would be cleaner and more readable than the multi: scheme. \
(Things like gzip and bzip2 wouldn't really require the bracketing, but I think it's \
needed for consistency. The current gzip:/dir/file style URLs could still be \
supported for compatibility.)

The difference in syntax of course also suggests a difference in implementation. The \
multi: scheme would only require one new ioslave that would be able to glue existing \
slaves together, probably using temporary files.

The bracketing scheme on the other hand would require changes to all the relevant \
ioslaves, replacing code for accessing the local file system with code for emulating \
random access to the nested ioslave. Much of that though could be factored out into a \
common base class (KIO::FilterSlave?). 

This would also prepare it nicely for ioslaves that directly support random access, \
whereas the multi scheme couldn't do that without making substantial changes to the \
filter-style ioslaves too.


[prev in list] [next in list] [prev in thread] [next in thread]