Drb / ActiveRecord as Application Server for Qt/Ruby client

ruby-talk
1

Logan Capaldo wrote:

···

On Aug 4, 2006, at 3:24 AM, Philippe Lang wrote:

Hi,

I intend to start a new project with the following architecture:

Server:
-------
- Postgresql database
- ActiveRecord
- Distributed Ruby Server

Client:
-------
- Distributed Ruby Client
- Qt/Ruby GUI

Drb is not really an "Application Server". Normally, you expect
features like "Connection Pooling" from such a server, and much more.

Is it safe and robust, anyway, on an intranet composed of a hundred
of client computers, to marshall all ActiveRecord objects through a
simple drb server?

Has anyone done this already?

Your reactions are more than welcome!

Thanks

If you are just gonna marshal the AR objects and send them
across the network, why even have a server / client
architecture? Just stick the AR code in the "Client" and let
PostgreSQL worry about concurrency.

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.

---------------
Philippe Lang
Attik System

2

You're already using ActiveRecord..why not throw the rest of the Rails stack in and use REST, XML-RPC or SOAP?

···

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.

--
~akk

3

Quoting Adam Keys <adam@therealadam.com>:

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.

···

On Aug 4, 2006, at 12:20 PM, Philippe Lang wrote: