Proposal for a new KIO API: KMount/KMountModel
nf2 at scheinwelt.at
Sat Mar 1 11:21:08 GMT 2008
Aaron J. Seigo wrote:
> On Friday 29 February 2008, nf2 wrote:
>> Also, it's difficult to display mounts/volumes in arbitrary locations in
>> the file-management hierarchy: You can set up ServiceMenues and custom
>> mimetypes to add the unmount action to such items (that's what i'm
>> currently doing in my remote:// implementation), but you still get
>> "delete" or "copy" entries in the context menu which don't make much
>> sense for mounts/volumes. This makes me believe that mounts are special
>> KFileItems, which have to be recognized appropriately (i.e with
> i understand the problem, but i'm not sure abstracting-the-abstraction-layer
> is the best answer here as it means yet another layer of software.
> it would be great if one of the following were to happen:
> * the layers under Solid spoke this stuff (e.g. modify the HAL layer to report
> on such "virtual" mounts)
> * barring that, the Solid backends for platforms that support things such as
> FUSE were made aware of them.
> the downside of the second approach is that it does start to pervert Solid
> from being a purely literal hardware system in this one case, but it is where
> i would expect to find this stuff and will give us exactly one place to point
> people to, instead of saying "well, if you want user space software mounts
> too, then you need to use this other API as well as Solid, otherwise you can
> just use Solid ..." that sounds really messy.
> now, if these user space mount systems are just too ugly to access from Solid,
> maybe that's a source of the problem as well.
Its actually quite tempting to use Solid for this. I already did it by
making the Solid implementation dlopenable to smuggle in the GVFS
mounts, but Kevin Ottens didn't like that ;-).
"Jack of all trades" APIs are quite nice (KIO is also a candidate), but
they have one big drawback: Because they are used for all kind of
different purposes, they can become a millstone around your neck when
trying to move forward. Therefore i believe it's right from software
design to encapsulate them whenever using them in a very specific
context (here: file-management). "Abstracting-the-abstraction-layer" is
not a bad thing at all.
More information about the kde-core-devel