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

List:       kde-core-devel
Subject:    Re: [RFC] One ioslave to rule them all...
From:       Gábor_Lehel <illissius () gmail ! com>
Date:       2005-06-25 23:03:28
Message-ID: 9cfeadb8050625160362a152b4 () mail ! gmail ! com
[Download RAW message or body]

Not related to your actual question, but wouldn't it make sense to
have system:/ point at applications:/ as well?
(Related to your question, I agree, but don't think I have the
credentials to give my opinion any sort of weight... the other issue
with the Unix file system, besides its organization, is the case
sensitivity.)

On 6/26/05, Kévin Ottens <ervin@ipsquad.net> wrote:
> Hello list,
> 
> I'd need some opinions about the work I've done until now and about my current
> plans about system:/. The basic idea behind this ioslave was to have one root
> allowing desktop users to easily browse the relevant places in the system. I
> want to push the idea further hence why I need to know if there are
> suggestions or objections.
> 
> In order to have this possible I developed mainly three ioslaves:
> - media:/ which allows to deal with your partitions, removable media, cdroms,
> etc.
> - remote:/ which allows to have "remote folders" and is possible to use thanks
> to knetattach.
> - home:/ which displays home directories of the users being in the same groups
> than the current user (because it's generally more relevant to share files
> with them), and the current user home directory.
> 
> Currently system:/ points to media:/, trash:/, remote:/, settings:/ and home:/
> (which was committed yesterday). home:/ being the last part of my great evil
> plan : hiding the real file hierarchy!
> 
> I'm now almost able to do it, in fact if I could even do it now. Some of you
> may wonder "why hiding the unixian file hierarchy??? and push use of
> system:/???".
> The answer is simply that for a desktop user this unix file hierarchy is an
> implementation detail.
> 
> So, the current status of what I've done is exactly this : if you start
> browsing using system:/ you can stay in this virtual hierarchy and do all
> your daily work using it (as a desktop user, not a sysadmin).
> 
> So the user could use only this, but some entry point to the unix filesystem
> still remain, in particular the shortcuts to the home directory...
> 
> Where I'd like to go is the following : replace $HOME with home:/$USER
> everywhere, this way the user will be "on the right track" by default (in the
> system:/ hierarchy).
> 
> Of course this would raise some issues on interoperability mainly because
> there's no consensus about the available VFS protocols between desktops. I
> currently see two problems in this area (I'll use media:/ as example since
> it's older and more known, but everything I'll present is true with home:/ as
> well) :
> 
> 1) Opening a file in the system:/ (media:/) hierarchy.
> When opening a file with an application, the application is launched thanks to
> its desktop file, and %u is replaced with the file URL (a media:/ URL for
> example). It'll work flawlessly with most KDE applications since they support
> KIO. But, some of them don't really support KIO completely (Kaffeine for
> example because it uses xine which only support some protocols like http and
> file). Moreover, non-KDE applications know nothing about media:/ URLs!
> 
> Then two things have been introduced:
> - KIO::NetAccess::mostLocalURL() which allows KDE applications to resolve an
> URL to a file:/ URL if needed (and if possible).
> - X-KDE-Protocols key in desktop files, which allows to restrict the set of
> supported protocols for an applications. Anything not present in this set is
> automatically resolved to file:/ URLs if possible before launching the
> application.
> 
> This way, we keep the compatibility with most applications, and KDE
> applications are able to have more control on the process. I then consider
> this issue as solved, the real solution would be of course to ensure that any
> non-KDE application could deal with any KDE URL but that's definitely not
> feasible currently, it would require a common VFS across all desktops,
> something that we won't have before a long time IMO.
> 
> 2) Drag and Dropping a file from the system:/ (media:/) hierarchy.
> It's the same kind of issue than opening a file. The main difference being
> that the application is already running, so the only counter-measure that can
> apply is KIO::NetAccess::mostLocalURL(), then only KDE applications can
> resolve the URLs to file:/ URLs... I've find no real way to make it work for
> non-KDE applications. Suggestions are welcome!
> 
> 
> Now I'm pondering on what to do :
> a) Replacing $HOME with home:/$USER right now?
> b) Replacing $HOME with home:/$USER for KDE 4 only?
> c) Give up the whole idea?
> d) Something else?
> 
> Of course I tend to think I should apply a), but I would consider b)
> acceptable whereas I really dislike c). Of course, I'm open to any
> interesting "d)" proposal.
> 
> Any opinions? advices?
> 
> Regards.
> --
> Kévin 'ervin' Ottens, http://ervin.ipsquad.net
> "Ni le maître sans disciple, Ni le disciple sans maître,
> Ne font reculer l'ignorance."
> 


-- 
Work is punishment for failing to procrastinate effectively.

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