KDE is not an OS platform... (And neither is Gnome)

[Benoit Jacob]

2009/10/30 Michael Pyne <mpyne at kde.org>:
> On Friday 30 October 2009 12:20:49 Benoit Jacob wrote:
>> I just would like to understand if there's a real reason anymore for
>> not letting KIO/GVFS go through the native VFS on Linux (and perhaps
>> other *nix). Again, on other exotic platforms, the statu quo seems
>> good enough.
>
> There's no reason we can't (just modify the kioslave for #if Q_OS_FOO ;)

I was actually about to write again to this list to remark that there
were still possibilities open!

>
> I think a saner alternative to integrating GVFS into KIO would be to support
> the IO-transfer API in use (assuming they use an out-of-process model, if they
> don't we can just fork() kio-gio bridges though.  I wonder if this is how
> nf2's bridge works? :)
>
> Once we can support KIOSlaves and GIO from KIO then perhaps we can standardize
> a IO virtualization interface on XDG so that the actual IO backends of KIO and
> GVFS could be used interchangeably.  (This also allows for the backends to be
> implemented in languages other than C, which is good IMO).
>
> Really making something like FUSE that "backend API" would probably be best
> long-term, except that it wouldn't work under Windows or OS X (and possibly
> BSD?)
>
> But either way we don't have to port away from KIO, GNOME doesn't have to port
> away from GVFS, but we get the benefit of shared IO backends (e.g. GNOME could
> use my kio_perldoc ;)
>
> I'm sure there's more to it than that but I don't see why that can't be a good
> starting step.

Your proposal sounds a lot more informed than anything I could have
formulated as far as the specifics of KIO and GVFS are concerned.

However I just realized that there is this other possibility, that
perhaps "saves" my proposal (so there would be this alternative path):

nf2 wrote:
> there is a reaon why GVFS just provides FUSE as a
> secondary channel. For instance FTP can't be mapped into the expected
> POSIX behavior properly, therefore GVFS just mapps FTP read-only.

Then what do you think about this: mangle these FTP commands into
special pseudo-paths. Just like website designers mangle certain
special operations into special URLs. For example, if FTP has a
command" make_coffee" to which you want to pass the arguments 42 and
"hello", you could design your filesystem such that doing a fopen() on
the path
  "/mountpoint/ftp?command=make_coffee&arg1=42&arg2=hello"
results in this command being executed. Even if this were too awful an
interface for anyone to be interested in using directly, there would
still be the advantage of letting KIO and GVFS interoperate
seamlessly. Then in practice, most cases would result in reasonable
paths and so that would mean that the whole system can use that.

At this point, not seeing any fundamental reason why this shouldn't
work, I think i'll try to code that when i find the time!

Benoit