Pau Garcia i Quiles wrote:
Rails stack in and use REST, XML-RPC or SOAP?
this is described here:
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.
Hi,
My initial idea was to use Qt on the client only, where no server
process is listening at all. When opening windows, reponding to user
activity in general, I thought it would be possible to call the Drb
Server, and get an ActiveRecord object, very simply, and then populate
the Qt controls with the data found in the marshalled object.
require ‘drb’
DRb.start_service()
obj = DRbObject.new(nil, ‘druby://localhost:9000’)
puts obj.getflowers
I haven’t had the time to test that, so I miss a point maybe, but I
don’t see exactly how your explanation applies in this context…
Philippe L. wrote:
The problem with QtRuby and DRb, XML-RPC, EventMachine, etc
listener) and have them communicate through DCOP. If your
puts obj.getflowers
I haven’t had the time to test that, so I miss a point maybe, but I don’t see exactly how your explanation applies in this context…
Philippe L.
Attik System
That general idea will work, and DRb is a good Ruby RPC framework.
However, ActiveRecord expects the database to be locally-available and
is quite “chatty” with the database. When DRb sends an instance of an
ActiveRecord across the wire, the client unmarshals it and loads the
ActiveRecord::Base class, and ActiveRecord::Base tries to initialize its
table columns by checking the database schema. This obviously doesn’t
work so well unless your client has direct access to the database.
You can work around this by adding ‘include DRbUndumped’ to your
ActiveRecord subclasses. This essentially makes DRb send a stub to your
client, and then every method invocation is a remote call. That works OK
for limited use, but bogs down when your client makes many remote calls.
This is a long way of saying that any moderately-complex remote GUI
client will need its own “remote transfer objects”. Either SOAP Structs
or just your own simple Ruby classes.
I think this presentation (PDF) is a helpful summary:
http://www.vanruby.com/system/files?file=20051025-soap4r-emil_marceta.pdf
Doesn’t QTRuby have a way to spawn a callback thread off of the main
event loop? Kind of like Swing’s invokeLater() or Fox’s Timers and
Chores? I’d think that you would want to do that for your remote calls.
Scott
Quoting Scott W. [email protected]:
Doesn’t QTRuby have a way to spawn a callback thread off of the main
event loop? Kind of like Swing’s invokeLater() or Fox’s Timers and
Chores? I’d think that you would want to do that for your remote calls.
Qt::Timer. Its behavior is described in Rubyforge-Forum messages I
told you in the previous message.