KIO: separating the API from the implementation

[nf2]

hi,

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...

 jobclasses.h:

things like "packedArgs" and "command" should probably not be visible in 
the public API...

SimpleJob(const KUrl& url, int command, const QByteArray &packedArgs,
 bool showProgressInfo);

i don't know if the Slave should be visible in the public interface 
(what if there is no Slave behind the Job)

 Slave *slave() const { return m_slave; }


KIO::UDSEntry

perhaps it shouldnt subclass QHash, because this makes it harder to 
change the internal model.

also, i believe KIO::UDSField should not be part of the public API...

btw, i have seen that GVFS moves to a string-key model with name-spaces:

"std:type"
"std:flags"
"std:name"
...

/* Unix specific attributes */

"unix:device"
"unix:inode"
"unix:mode"
...


Error codes: it would be cool if the list of VFS error codes and their 
meaning could be standardized via freedesktop (many errors have the same 
meaning, thus they can be shared, and perhaps there should be reserved 
ranges for implementation specific codes (for KIO, GVFS, VIO,...)

0 OK
1024-4095   generic codes (like ERR_FILE_ALREADY_EXIST)
4096-6143   KIO
6144-8191   GVFS
8192-10239 VIO
...


... just some thoughts ... :-)

regards,
norbert