[RFC] One ioslave to rule them all...

[Thiago Macieira]

Kévin Ottens wrote:
>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.

I agree with that. Users don't have to understand the filesystem 
hierarchy. It's a detail.

Users also lose files, forgetting where they placed them. They also let 
their directories (they call it "folders" :->) grow to absurd sizes. I 
know because I do that. But that's a different issue, and we may be able 
to fix it in the future.

>- 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 should be made an fd.o recommendation, and "X-KDE" removed. We should 
have two profiles: basic and kde. "basic" would be simple network 
protocols, like ftp, http, https and file (I'm not sure if we can include 
smb, sftp and fish). "kde" would stand for the whole kde set of ioslaves.

Desktop files with missing or unknown entries would default to "basic". 
That way, we can work right now with non-KDE apps.

There's another problem: KDE apps that don't use KDE 3.4 or 3.5 (for 
instance, amaroK). They've added a hack by calling dcop to work 
"mostLocalURL" on themselves.

> 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.

Maybe with KDE4, if we define a set of KIO-like calls over DBus and a 
workable wire protocol. Maybe then VFS will be standardised.

>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.

I'd say d: replace it now in trunk in key places and let people test for a 
few weeks, but be prepared to revert it before the release/freeze, if 
required.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

5. Swa he géanhwearf tó timbran, and hwonne he cóm, lá! Unix cwæð "Hello, 
World". Ǽfre ǽghwilc wæs glæd and seo woruld wæs fréo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050625/0ef4724b/attachment.sig>