[Kde-bindings] XPath is my friend

[Richard Dale]

I've been reading Ashley's latest blog:
http://jahqueel.blogspot.com/2005/06/bindings-xpath-is-my-friend.html

The idea of breaking down the library into one .so file per class and loading 
on demand sounds interesting. I'm not sure about keeping the xml as text 
inside the .so file, and then adding it to the DOM at runtime. It seems a bit 
wasteful having it take up memory when it's no longer needed - wouldn't it be 
better to have the xml as text files seperate from the .so libs?

How will the C# bindings work - are you intending to divert all the calls 
through Proxy.Invoke() like I was going to do when I last tried? Or if you 
were going to do something more conventional, where each C# method calls the 
corresponding C++ method. There doesn't seem to be the need to use Smoke 
introspection, and mainly it would just need virtual method callbacks 
presumably via the new scheme using slots/signals.

"I expect to create an XSL stylesheet for the C++/moc4 Smoke binding, another 
one for the O'Caml binding, and yet another one for the C# binding."

Does the XSL stylesheet for C# just generate C# code, which in turn uses the 
C++/moc4 Smoke bindings? Or does it generate both C# and C++ code?

The disadvantage of having three different libs is that if we have a kde 
plugin api, and write some plugins in O'Caml, some in C# and some in ruby 
there will be three libs loaded taking up more memory than if there was a 
single runtime Smoke lib for all languages.

-- Richard