Proposal for a new KIO API: KMount/KMountModel

[nf2]

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
>> KFileItem::isMount()).
>>     
>
> 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.

Cheers,
Norbert