[PATCH] remove UDSEntry from the public KIO API?

[nf2]

Jos Poortvliet wrote:
> On 7/30/07, *nf2* <nf2 at scheinwelt.at <mailto:nf2 at scheinwelt.at>> wrote:
>
>     Richard Moore wrote:
>     > On 7/28/07, nf2 <nf2 at scheinwelt.at <mailto:nf2 at scheinwelt.at>>
>     wrote:
>     >
>     >> I see, but there is some kind of relationship between kfile and
>     >> libsolid. I reckon this has to change when plugging GVFS in. In
>     this
>     >> case, Kfile should probably use the gvfs API for drives and volumes
>     >> instead...
>     >>
>     >
>     > I'm curious why we would be pluging GVFS in at all? I don't remember
>     > any discussion about us using it.
>     >
>     > Rich.
>     >
>
>     I believe a discussion whether the core-engine of file-management
>     (which
>     KIO tries to be - at least for network-resources) can be in the
>     desktop
>     layer, or not, wouldn't be bad. Perhaps the problem is not as obvious
>     for desktop developers than for everyone else. Generally i think that
>     users don't care about the "K" or "G" in front of application names.
>     They rather expect that everything which is a "linux application"
>     will
>     run on any desktop in the same quality and hit the install button.
>     Finding out that different applications provide totally different and
>     incompatible file-management models (in file-choosers for
>     instance) will
>     most likely frustrate them. As long as someone only works with local
>     files, he won't realize. But working with documents on
>     file-servers can
>     be a painful experience. GVFS might be an opportunity to fix those
>     file-management inconsistencies...
>
>
> KIO works for non-KDE apps - it automatically copies the file to a 
> temporary location, and monitors the file for changes, uploading it 
> when it changes. Works pretty good. Second, there is KIO-FUSE, which 
> could be used to let non-KDE apps do their thing without knowing 
> they're not working on local files
>
> FUSE is meant for a below-desktops system anyway, so that would 
> probably be a better way to go. I'd rather see (for once) work from 
> the other side to work with this, but I guess that's just a dream. At 
> least, you'd have an easier time getting KIO to (optionally) use GVFS, 
> even though that still has to be written, than GVFS use KIO, even 
> through Fuse ;-) So you choose to do the right thing, I guess.
>
> I guess the dev's don't want to cripple or de-stabilize the (proven 
> and working) KIOslaves for something which MIGHT [1] exist in the 
> future, and we MIGHT use. GVFS will also introduce a new dependency, 
> and I guess it's not platform independent either, is it? So I guess 
> they're sceptical, and won't turn heaven and earth to get support for 
> this.
I think the design and dependency chain of GVFS makes it pretty desktop 
independent (and therefore interesting for KDE). FUSE might also be a 
possibility - that's why i invested quite some time in writing libfusi - 
but there are difficulties with mapping certain filesystems into the 
POSIX layer (problems with atomic saves on webdav, file permissions,...)

But what's a platform, what's a desktop and what's a desktop 
environment? And what should be provided by which layer? I believe the 
lack of a clear concept is one of the reasons why linux didn't take off 
as desktop operating system.

I would call Windows (without Office and IE) a platform - or on Linux 
the kernel, xorg, CUPS, HAL, the fd.o standards,... make up the 
platform. I guess the platform is the infrastructure that everyone uses. 
Naturally, the file-system - also the virtual file system - should be 
part of the platform (that's where things went wrong...). My feeling is, 
that on Linux generally this common layer is too thin.

Norbert