KIO: separating the API from the implementation

[nf2]

Thiago Macieira wrote:
> nf2 wrote:
>   
>> i wonder if the public API of KIO could be made more "abstract" for KDE4
>> (to be able to plug other VFS implementations, but also to make
>> innovation easier for KDE). i believe there are many classes, members,
>> methods and enums in the KIO namespace, which should not be exposed to
>> the "library user". For instance, what's the point of having Slave or
>> SlaveInterface, Scheduler, enum Message... in the public API... ?
>> Perhaps such things should be moved to a KIO::KDEImpl:: namespace...
>>     
>
> I want to do some work there, but given my current amount of free time 
> available and the upcoming freeze dates, I don't think we can pull it 
> off.
>
>
>   
yes - seems quite impossible in such a short period of time. do you 
think it would work to create a new KIO API in a separate namespace 
("kio4" or "kioapi") and depricate the old API during the 4.x series? 
the new API could use the old API internally, but also wrap other VFS 
libraries...

there are lots of things in KIO which could be made nicer. for instance 
why is "get" and "put" handled by the same class "TransferJob", although 
a "get" job will never emit a "dataReq" signal and a "put" job will 
never emit a "data" signal? Having separate "GetJob" and "PutJob" 
classes would probably make the API easier to understand...

norbert