Re: Plans for gnome-vfs replacement
- From: Mourad De Clerck <mourad aquazul com>
- To: Alexander Larsson <alexl redhat com>
- Cc: gnome-vfs-list gnome org
- Subject: Re: Plans for gnome-vfs replacement
- Date: Mon, 16 Oct 2006 15:40:56 +0200
On 29/09/06 09:16, Alexander Larsson wrote:
> On Wed, 2006-09-27 at 23:52 +0200, Mourad De Clerck wrote:
>> I was just wondering if it would still be possible to refer to a file
>> through chained URIs (or IRIs, or whatever new alternative system you're
>> proposing)
<snip>
>> in that case, how do you pass parameters to the chained parts, like for
>> instance a zip password for the last part of the chain? Serializing it
>> in the URI/IRI itself (...tory/file.txt?password=12345) might be a bit
>> ugly...?
>
> I dunno. This never quite worked in gnome-vfs, and the KIO guys said it
> was nothing but problems for them. I'm not sure its really all that
> important.
Well even relatively basic things like accessing a zip file on a samba
share would need it. Unless you expect users to copy the file to their
desktops first? Or do you mean that users would be able to browse them,
but there would simply be no way to actually refer to them (state is
hidden) - so no referring to those nested-mount-files in .desktop or the
mentioned "shortcuts"?
>> imap://user mail domain org:143/fetch%3EUID%3E.INBOX%3E666#mime:///attached_file.zip#zip:///directory/file.txt
>>
> Of course, the above example URI is a prime example of all that is wrong
> with using general URIs for a vfs. Any well-defined filesystem semantics
> that will also support an imap backend is gonna suck raw eggs for actual
> users of normal files.
what's so special about IMAP? Its ACLs are a bit weird, but from what
you described I understood ACL-type metadata to be backend-dependant in
any case. Operations like you describe (read-entire-file, copy-file,
...) would not be a bad match for imap either (posix-style would be
harder). In any case, it was just meant to be a pathological example.
-- Mourad
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]