[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Desktop <-> Web

Trans

1/15/2009 5:10:00 PM

I want to interface a desktop application to a backend web
application. What's the easiest way to go about this --what's the best
way to communicate between the two?

Thanks,
T.
18 Answers

Brian Candler

1/15/2009 9:40:00 PM

0

Aria Stewart wrote:
> On Fri, 2009-01-16 at 02:09 +0900, Trans wrote:
>> I want to interface a desktop application to a backend web
>> application. What's the easiest way to go about this --what's the best
>> way to communicate between the two?
>
> SOAP and XML-RPC are both good options, as is a REST-style interface.
> Net::HTTP on the client, whatever on the server.

There are APIs on the client side which are higher level than Net::HTTP.

* xmlrpc is bundled with Ruby
* soap4r (shudder) is bundled with Ruby
* ActiveResource is a REST client

Which you use typically depends on what the backend application
provides. Note that all three use XML, and so are inefficient for large
binary transfers, as you have to base64 encode them.

If you are writing both front and backend, you could consider other
protocols (e.g. DRb). That's harder to scale though, whereas it's easy
to set up a HTTP proxy for load-balancing.

The above are all synchronous protocols. If asynchronous semantics suit
you better (e.g. submit a request, poll for the response later) then you
could talk to a queuing system, e.g.
* Memcache protocol - Starling
* AMQP protocol - various servers inc RabbitMQ
* Stomp protocol over HTTP - various servers inc Apache ActiveMQ
* ... lots of others

Another option is to use XMPP (Jabber) as the transport. There is xmpp4r
as endpoint, and a selection of XMPP servers to route your messages
through. xmlrpc can run over XMPP. But this is likely to be overkill for
a single-server scenario.

Finally, consider seriously the possibility of using a plain web browser
as the client, using HTML and AJAX over HTTP. It's maybe a bit harder to
build an application with a desktop "feel" but it is doable (see Google
Docs), and you don't need to distribute any code to the clients.

Rails has particularly good support for this, and can generate most of
the necessary Javascript for you. However if you're not already a Rails
user, there's a steep learning curve to get there.
--
Posted via http://www.ruby-....

James Gray

1/15/2009 9:47:00 PM

0

On Jan 15, 2009, at 3:39 PM, Brian Candler wrote:

> * soap4r (shudder) is bundled with Ruby

Ruby 1.8. I believe it's gone in Ruby 1.9.

James Edward Gray II

Martin DeMello

1/16/2009 5:21:00 AM

0

On Thu, Jan 15, 2009 at 10:39 PM, Trans <transfire@gmail.com> wrote:
> I want to interface a desktop application to a backend web
> application. What's the easiest way to go about this --what's the best
> way to communicate between the two?

Are you writing the webapp too?

martin

Trans

1/16/2009 10:18:00 AM

0



On Jan 16, 12:20=A0am, Martin DeMello <martindeme...@gmail.com> wrote:
> On Thu, Jan 15, 2009 at 10:39 PM, Trans <transf...@gmail.com> wrote:
> > I want to interface a desktop application to a backend web
> > application. What's the easiest way to go about this --what's the best
> > way to communicate between the two?
>
> Are you writing the webapp too?

yes.

Martin DeMello

1/16/2009 11:40:00 AM

0

On Fri, Jan 16, 2009 at 3:48 PM, Trans <transfire@gmail.com> wrote:
>
>
> On Jan 16, 12:20 am, Martin DeMello <martindeme...@gmail.com> wrote:
>> On Thu, Jan 15, 2009 at 10:39 PM, Trans <transf...@gmail.com> wrote:
>> > I want to interface a desktop application to a backend web
>> > application. What's the easiest way to go about this --what's the best
>> > way to communicate between the two?
>>
>> Are you writing the webapp too?
>
> yes.

I'd suggest returning data from the webapp as json, then, and reading
it as yaml from the ruby end. I did that in a recent project at work
and it was pretty painless. The benefit is if you want to build a rich
browser-based frontend later, client side javascript can use the same
json objects.

martin

Trans

1/16/2009 12:18:00 PM

0



On Jan 16, 6:39=A0am, Martin DeMello <martindeme...@gmail.com> wrote:

> I'd suggest returning data from the webapp as json, then, and reading
> it as yaml from the ruby end. I did that in a recent project at work
> and it was pretty painless. The benefit is if you want to build a rich
> browser-based frontend later, client side javascript can use the same
> json objects.

I thought about this as well, but how did you go about transporting
the json?

At the moment I've taken Aria's suggestion of using XML-RPC, that's
working fine via the XMLRPC::WEBrickServlet. But ultimately I want to
use Rack instead. An example of a simple Rack-based JSON servlet would
be awesome. Anyone have one?

T.

Trans

1/16/2009 12:32:00 PM

0



On Jan 15, 4:39=A0pm, Brian Candler <b.cand...@pobox.com> wrote:
> Aria Stewart wrote:
> > On Fri, 2009-01-16 at 02:09 +0900, Trans wrote:
> >> I want to interface a desktop application to a backend web
> >> application. What's the easiest way to go about this --what's the best
> >> way to communicate between the two?
>
> > SOAP and XML-RPC are both good options, as is a REST-style interface.
> > Net::HTTP on the client, whatever on the server.
>
> There are APIs on the client side which are higher level than Net::HTTP.
>
> * xmlrpc is bundled with Ruby
> * soap4r (shudder) is bundled with Ruby
> * ActiveResource is a REST client
>
> Which you use typically depends on what the backend application
> provides. Note that all three use XML, and so are inefficient for large
> binary transfers, as you have to base64 encode them.
>
> If you are writing both front and backend, you could consider other
> protocols (e.g. DRb). That's harder to scale though, whereas it's easy
> to set up a HTTP proxy for load-balancing.
>
> The above are all synchronous protocols. If asynchronous semantics suit
> you better (e.g. submit a request, poll for the response later) then you
> could talk to a queuing system, e.g.
> * Memcache protocol - Starling
> * AMQP protocol - various servers inc RabbitMQ
> * Stomp protocol over HTTP - various servers inc Apache ActiveMQ
> * ... lots of others
>
> Another option is to use XMPP (Jabber) as the transport. There is xmpp4r
> as endpoint, and a selection of XMPP servers to route your messages
> through. xmlrpc can run over XMPP. But this is likely to be overkill for
> a single-server scenario.
>
> Finally, consider seriously the possibility of using a plain web browser
> as the client, using HTML and AJAX over HTTP. It's maybe a bit harder to
> build an application with a desktop "feel" but it is doable (see Google
> Docs), and you don't need to distribute any code to the clients.
>
> Rails has particularly good support for this, and can generate most of
> the necessary Javascript for you. However if you're not already a Rails
> user, there's a steep learning curve to get there.

Thanks Brian. Lots of useful info hear. I actually did create web-
browser client at first, but the problem is that I needed to save
files to the local file system, and that was just too cumbersome with
a web-client --it required that I had a local server running too,
which added additional headaches. I considered something like Google
Gears, Adobe Air, etc. but that ended real quick when I discovered
none of them supported 64bit Linux, which I run.

(Aside Rant: What the hell is going on with 64 bit support btw? Why
the hell are we stuck in 32-bit world? I mean how long has has it
bloody been already since 64 CPUs hit the mass-market? It's just
intolerable! Honestly, I can't say enough bad things about this state
of affairs. It really has to be the pinnacle example of how the whole
industry has gone to hell in a hand basket.)

So I'm using Shoes on the front-end. And for the most part that's
working pretty good so far.

T.

Brian Candler

1/16/2009 1:47:00 PM

0

Thomas Sawyer wrote:
> So I'm using Shoes on the front-end. And for the most part that's
> working pretty good so far.

Makes sense.

Some years ago I wrote a system which used DRb over HTTP: I had to
modify the DRb code slightly to do this (adding support for fastcgi
server processes). That was nice as it let me use native Ruby objects,
but if hashes containing just text are OK for you (and make sure they're
only ASCII or UTF-8 text), xmlrpc should be fine.

I did come across YAML RPC once; there's some code floating around on
the net for that, but it's possibly stale now.

I don't know if there's any sort of standard for "JSON RPC". I suspect
it just means REST with JSON response objects. If you want to try that,
and to keep as close to Rack as possible, then I suggest layering
something very lightweight like Sinatra on top of it. Of course, Rails
has render :json. Remember too that json supports *only* Unicode
strings, so anything binary needs base64 encoding.

Don't forget that your backend app will probably need some sort of
authentication framework, possibly just HTTP Basic Auth for simplicity,
to stop random clients making requests.

Even if you don't use a browser as a front-end, you might be able to
steal some ideas from those who do. e.g.
http://beebole.com/blog/pure/generate-html-from-a-json-without-any-template-but-html-and-j...

Anyway, that's just a few random thoughts.

Regards,

Brian.
--
Posted via http://www.ruby-....

Brian Candler

1/20/2009 10:17:00 AM

0

Thomas Sawyer wrote:
> ultimately I want to
> use Rack instead. An example of a simple Rack-based JSON servlet would
> be awesome. Anyone have one?

How about this with Sinatra, which sits on top of Rack:

--- myapp.rb ---
require 'rubygems'
require 'sinatra'
require 'json'
require 'widget'

get '/widgets.json' do
Widget.all.to_json
end

get '/widgets/:id.json' do
Widget.find(Integer(params[:id])).to_json
end

post '/widgets.json' do
item = JSON.parse(request.body.read)
raise "Bad object" unless item.is_a? Widget
Widget.add(item).to_s
end

--- widget.rb ---
# Rubbish model, not thread-safe!
class Widget
attr_accessor :id, :name, :price
def initialize(id, name, price)
@id, @name, @price = id, name, price
end
def to_json(*a)
{
'json_class' => self.class.name,
'data' => [ @id, @name, @price ],
}.to_json(*a)
end
def self.json_create(o)
new *o['data']
end
def self.all
@all ||= []
end
def self.add(item)
@seq ||= 0
@seq += 1
item.id = @seq
all << item
return @seq
end
def self.create(*args)
add(new(*args))
end
def self.find(id)
all.find { |item| item.id == id }
end
end
Widget.create(nil, "flurble", 12.3)
Widget.create(nil, "boing", 4.56)
--
Posted via http://www.ruby-....

Brian Candler

1/20/2009 10:37:00 AM

0

P.S. I'm not sure what is the "right" way to serialize Ruby objects in
JSON.

I took the to_json and json_create code from the ruby json library
documentatation, which gives

{"json_class": "name", "data": ["values", ...]}

Maybe it would be more natural to serialize a Ruby object as
{"attr_name": "attr_value", ...}, since { ... } itself denotes an
"object" according to the JSON specification.

However I've also seen examples on the web using a hybrid:

{"json_class": "name", data: {"attr_name": "attr_value", ... } }
--
Posted via http://www.ruby-....