[Kde-bindings] Splitting up the Smoke qt library into modules

[Gary Greene]

On 10/21/09 10:36 AM, "Richard Dale" <rdale at foton.es> wrote:
> While we're discussing BIC changes to the smoke libs, I wonder if it would be
> a good idea to split up the libsmokeqt library into small libs. The small size
> of the Smoke libs is becoming a big advantage relative to other bindings
> libraries, and it we split them up a bit maybe the advantage would  be larger
> still. Or is the a performance tradeoff in that searches for a class or method
> would have to cross Smoke module boundaries more often and that would slow
> things down? It is worth measuring somehow?
> 
> For a start I really thing we should remove QtXml and QtSql from the base
> Smoke library as nearly all dynamic languages have their own versions of there
> which are quite likely to be better than a wrapped C++ version. For example,
> there in no point in using the QtSql classes in Ruby because Rails
> ActiveRecord is so much better.

Same with Perl's DBI and DBIx module namespaces, Doing SQL through Qt seems
a little out of place in those cases.
 
> Then the decision is whether it is a good idea to map one Qt module onto one
> Smoke library. 
> 
> One example for me, is that I think a separate QtCore smoke library would be
> useful for Semantic web applications, as I could use the Ruby bindings for
> QtCore, Soprano with the ActiveRDF Virtuoso adaptor with Wt::Ruby for the web
> app without the overhead of the QtGui library.

Agreed. This would lower the resident size of the app overall since we're
already dealing with the overhead of the interpreter and any other compiled
or interpreted code pulled in by an app. Bringing that footprint down is a
good thing :)

-- 
Gary L. Greene, Jr.
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.