[prev in list] [next in list] [prev in thread] [next in thread]
List: konq-bugs
Subject: [Bug 102265] nested kioslaves for archives
From: Andy Koppe <andy.koppe () ed ! ac ! uk>
Date: 2005-03-25 9:22:01
Message-ID: 20050325092201.30074.qmail () ktown ! kde ! org
[Download RAW message or body]
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
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. _______________________________________________
Konq-bugs mailing list
Konq-bugs@mail.kde.org
https://mail.kde.org/mailman/listinfo/konq-bugs
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic