Porting kio-slaves to GnomeVFS modules

[nf2]

Thiago Macieira wrote:

>nf wrote:
>  
>
>>>You'll need to reimplement the SlaveBase class in order to receive
>>>input from the Gnome-VFS master. However, bear in mind that you must
>>>respect the usual C++ Binary Compatibility guidelines when doing so.
>>>      
>>>
>>I think we can't use them "as is". So binary compatibility won't be
>>possible. The main reason is that io-slaves are designed to run async
>>only. Therefore they provide single methods for "get", "put" or
>>"readDir" and push back data with callbacks.
>>    
>>
>
>Binary Compatibility is not an option if you want to make anything useful. 
>You have to be binary compatible.
>
>You'll have the option to influence the ABI when KDE goes 4.0. But not 
>before, nor ever again until 5.0.
>
>  
>
Of course i need to take care of that. If i put them into a different 
library, which gets called by Wrapper (to sit in KIO or GnomeVFS), 
binary compatibility shouldn't be an issue. :-)

But i do have questions about kio-slaves and binary compatibility. For 
instance when i want to add fields to the AuthInfo class. GnomeVFS wants 
a "domain" field for SMB authentication for instance.

(see
http://cvs.gnome.org/viewcvs/gnome-vfs/libgnomevfs/gnome-vfs-standard-callbacks.h?rev=1.12&view=auto

GnomeVFSModuleCallbackFullAuthenticationIn / GnomeVFSModuleCallbackFullAuthenticationOut.

)

Let's say i want to inherit AuthInfo with the class "AdvancedAuthInfo".

The documentation says that's possible: "If you extend this class to add 
additional parameters do not forget to overload the stream insertion and 
extraction operators ("<<" and ">>") so that the added data can be 
correctly serialized."

But how does the deserializer know whether is receives a AuthInfo or 
AdvancedAuthInfo object?

Or would it be better to add a "openAdvancedPassDlg" method to 
SlaveBase. Would that break binary compatibility?

Regards,

Norbert