RE: Spring-rich killer: rails rich-client proposal

Rails
1

I am actually fairly familiar with XUL both as a standard and as an
implementation (i.e. mozilla’s XUL) and even know a little about XPCom
(cross-platform COM). Again I’m not trying to hold anyone’s feet to the
fire on any particular technology. But here are some of the issues that
would not come as “easy” as one might think with fullscreen-mozilla, XUL
and so-on.

  1. nothing beats a well implemented native GUI toolkit for speed and
    responsiveness
  2. native UI “affordances” such as “office-style toolbars”, nice looking
    context menus, dockable windows and so-on.
  3. integration with native (deployed) platform such as email clients,
    personal information managers, system trays and other native
    notification systems or applications crucial to your users’ business
    requirements
  4. capability to communicate directly with subsystems on user’s desktop
    such as peripherals (i.e. cash drawers), and print spools. A major user
    complaint is that few things are more annoying than having to click
    “print” twice (i.e. print a grid view that has a print button or
    file->print in the toolbar that produces a standard report for that grid
    but has to be generated as PDF then click print again).

I am not trying to take away anything from the technical merits of the
suggestions offered thus far. But I think they are only part of the
equation. The above list is just a few of the things that a rich-client
framework should set out to do. It’s all about convenience for the user
and to be fully convenient you have to get down and dirty with the
native platform. You can do this in a platform independent way. Java
has a lot of these issues solved with printing support and JDBC/ODBC
bridges, JNI and so on. Ruby has many of these features as well.

Swing was designed to solve some of the problems that others have solved
with WX-Ruby, Ruby-Tk, Ruby-Cocoa, FX-Ruby and so on. Spring-rich sets
out to produce a framework that removes a lot of the would-be “exercises
for the reader” such as handling events in an MVC sort of way,
data-binding, pluggable widget support, status bars and many of the
common things one would need in today’s common, native business
application. I think the reason we are compelled to use approaches such
as “fullscreen-Firefox” is because rails has not been extended in such a
way to make it easy to do native applications (yet). I am not saying
these approaches do not make sense for certain problems yet the problem
domain I am addressing has a lot more things that fall into the scope
besides just throwing a browser at the problem. I think that if we can
agree on that we can move forward and make sound decisions in our
implementation as did the developers of rails who in many ways had to
anticipate our needs to minimize mistakes and redundancy.

Thanks again for your time.
BR_joe

2

On Jan 31, 2006, at 7:46 PM, Joseph G. wrote:

responsiveness
user
framework should set out to do. It’s all about convenience for the
out to produce a framework that removes a lot of the would-be
problem
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

Joseph-

I have written a few custom applications using rubycocoa for the gui

and ActiveRecord on the back end with my own custom controllers that
don’t deal with http but just deal with rubycocoa. Its quite a nice
system to work with. Of course its not cross platform. I don’t know
if rails controllers that are tied to http and the request response
cycle are the right concept for a native style app. I do like the
idea of a nice ruby mvc framework with activerecord and a native app
style controller and view.

Please keep me informed if you start to write something like this.

Cheers-
-Ezra Z.
WebMaster
Yakima Herald-Republic Newspaper
[email protected]
509-577-7732

3

On 1/31/06, Joseph G. [email protected] wrote:

I am actually fairly familiar with XUL both as a standard and as an
implementation (i.e. mozilla’s XUL) and even know a little about XPCom
(cross-platform COM). Again I’m not trying to hold anyone’s feet to the
fire on any particular technology. But here are some of the issues that
would not come as “easy” as one might think with fullscreen-mozilla, XUL
and so-on.

  1. nothing beats a well implemented native GUI toolkit for speed and
    responsiveness

Nothing beats the amount of code and effort needed to implement this
either. I have been involved with apps containing close to a million
lines of GUI code.

  1. native UI “affordances” such as “office-style toolbars”, nice looking
    context menus, dockable windows and so-on.

If cross platform doesn’t matter then build a Windows specific app.
You’d be better off writing it in dotNET than Ruby. dotNET has all of
the Windows OS wrapped in convenient APIs.

  1. integration with native (deployed) platform such as email clients,
    personal information managers, system trays and other native
    notification systems or applications crucial to your users’ business
    requirements

This varies all over the map. I use gmail, how are you going to
integrate with that? Note that you can write your own XPCOM components
in C. C code can get to any integration library provided by the other
apps.

  1. capability to communicate directly with subsystems on user’s desktop
    such as peripherals (i.e. cash drawers), and print spools. A major user
    complaint is that few things are more annoying than having to click
    “print” twice (i.e. print a grid view that has a print button or
    file->print in the toolbar that produces a standard report for that grid
    but has to be generated as PDF then click print again).

Write XPCOM components to do this. Use XUL code to call the components.

Swing was designed to solve some of the problems that others have solved
with WX-Ruby, Ruby-Tk, Ruby-Cocoa, FX-Ruby and so on. Spring-rich sets
out to produce a framework that removes a lot of the would-be “exercises
for the reader” such as handling events in an MVC sort of way,
data-binding, pluggable widget support, status bars and many of the
common things one would need in today’s common, native business
application. I think the reason we are compelled to use approaches such
as “fullscreen-Firefox” is because rails has not been extended in such a

Read the Ruby mailing list. People are making wrappers for OpenGL and
other GUI libs. Rails is really oriented around paged displays and the
REST model. Some things don’t fit into this model - you can’t write a
CAD/CAM app using RoR.

way to make it easy to do native applications (yet). I am not saying
these approaches do not make sense for certain problems yet the problem
domain I am addressing has a lot more things that fall into the scope
besides just throwing a browser at the problem. I think that if we can
agree on that we can move forward and make sound decisions in our
implementation as did the developers of rails who in many ways had to
anticipate our needs to minimize mistakes and redundancy.

The browser model gives you something that the other don’t The
browser can run in three configurations. Thin client, thick client and
standalone. Thin client uses something like VNC or X for the display.
Thick client runs the browser and support components locally and the
server remotely. Standalone runs the client and server on the same
machine.

With XUL you don’t have to be limited to what is available in a normal
browser. With XUL you can create your own components both visual and
invisible.

You really need to consider the parameters of what you are building…
Is it only Windows standalone - use dotNET
Is REST model important, with lots of anonymous network users - use RoR
You want RoR but browser UI isn’t good enough - use RoR + XUL
Crossplatform and standalone - Ruby + wxWidgets
Windows only on highly available local net - dotNET again
CAD/CAM - OpenGL + C for speed
Game - direct X for widest platform availability

–
Jon S.
[email protected]

4

This is a slight tangent to the thread here, but has anyone come up
with a decent way to obfuscate (or distribute as a binary) a rails
application bundled with WEBrick?

I’m looking to productize a rails app, but my concern is distributing
the source out so that it’s easily copied. Ideally I would like to
distribute it as a compiled executable, though still use browsers as
the client.

5

On 2/1/06, Theodore M. [email protected] wrote:

This is a slight tangent to the thread here, but has anyone come up
with a decent way to obfuscate (or distribute as a binary) a rails
application bundled with WEBrick?

I’m looking to productize a rails app, but my concern is distributing
the source out so that it’s easily copied. Ideally I would like to
distribute it as a compiled executable, though still use browsers as
the client.

Distribute the app open source and charge for
upgrades/integration/customization. You will be surprised at how many
improvements your customers will send back to you.

I am much happier now that the majority of software I run is open
source. I used to really, really hate trying to debug broken apps
with a moron on the support call (that means you Microsoft). Now I fix
the minor things myself and send the patch to the maintainer, or I pay
someone to make the changes I need.

Don’t focus so much on revenue from the initial sale. If you do, that
means you need marketing and a sales force which are expensive.
Instead focus on the secondary revenue of support, integration and
customization. People will find the app and come to you instead of you
having to spend a lot of money trying to get them to initially buy the
app. Another strategy is to focus on back end revenue such as monthly
fees for hosting and data storage.

There are probably a million apps in the graveyard because they tried
to sell the app and didn’t have the market/sales clout to get an
initial revenue stream going. I have three dead startups like that in
my past.

Don’t forget that most of your customers are not software developers.
They will choose to pay you to do upgrades/integration/customization
rather than doing it themselves. The key to success is ending up with
a lot of customers, not how much you can initially extract from them.

–
Jon S.
[email protected]

6

Here’s some good advice for how to distribute a binary rails app on
Windows:

http://www.erikveen.dds.nl/distributingrubyapplications/rails.html

But it’s by no means hack-proof. It just makes the app more convenient
to run.

Carl