From: Pau Garcia i Quiles Date: 2006-08-06T06:01:46+09:00 Subject: Re: Drb / ActiveRecord as Application Server for Qt/Ruby client Quoting Adam Keys : > On Aug 4, 2006, at 12:20 PM, Philippe Lang wrote: >> >> I prefer a 3-tier approach, with all the buisness logic on the >> server, just like you would do with J2EE. Centralisation of code is >> a good thing I think. >> > > You're already using ActiveRecord..why not throw the rest of the Rails > stack in and use REST, XML-RPC or SOAP? The problem with QtRuby and DRb, XML-RPC, EventMachine, etc is each one of them has its own event loop. Once you call $qapp.exec in QtRuby, you application enters the Qt event loop and you cannot call anything outside that loop. The same goes for XMLRPC4R and the server.serve call: once you call myserver.serve, your application waits in an event loop, so you cannot run $qapp.exec because QtRuby does not work with Ruby threads. The only approach you can take to "fix" this is described here: http://rubyforge.org/forum/message.php?msg_id=3329 The explanation is here: http://rubyforge.org/forum/message.php?msg_id=3341 But you should realize this is more of an accident than a feature. The best solution for this problem is to implement your own protocol using QtRuby. If your QtRuby application is actually a Korundum application, another approach would be to have two independent applications (the Korundum app and the XML-RPC/EventMachine/whatever listener) and have them communicate through DCOP. If your application is a QtRuby 4 one, you may use DBUS as well but take in account the Ruby-DBUS bindings are quite old.