# RE: Spring-rich killer: rails rich-client proposal **URL:** \ **Category:** Rails\ **Created:** [February 1, 2006, 4:46am UTC](https://www.ruby-forum.com/t/re-spring-rich-killer-rails-rich-client-proposal/99655 "2006-02-01T04:46:56Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Joseph\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ea5d25/32.png) [@Joseph\_G](https://www.ruby-forum.com/u/Joseph_G)\ **Post date:** [February 1, 2006, 4:46am UTC](https://www.ruby-forum.com/t/re-spring-rich-killer-rails-rich-client-proposal/99655/1 "2006-02-01T04:46:56Z")
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 ---
**Author:** ![Joseph\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ea5d25/32.png) [@Joseph\_G](https://www.ruby-forum.com/u/Joseph_G)\ **Post date:** [February 1, 2006, 6:29am UTC](https://www.ruby-forum.com/t/re-spring-rich-killer-rails-rich-client-proposal/99655/2 "2006-02-01T06:29:37Z")
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 > removed\_email\_address@domain.invalid > [http://lists.rubyonrails.org/mailman/listinfo/rails](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 removed\_email\_address@domain.invalid 509-577-7732 ---
**Author:** ![Joseph\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ea5d25/32.png) [@Joseph\_G](https://www.ruby-forum.com/u/Joseph_G)\ **Post date:** [February 1, 2006, 4:50pm UTC](https://www.ruby-forum.com/t/re-spring-rich-killer-rails-rich-client-proposal/99655/3 "2006-02-01T16:50:44Z")
On 1/31/06, Joseph G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. removed\_email\_address@domain.invalid ---
**Author:** ![Joseph\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ea5d25/32.png) [@Joseph\_G](https://www.ruby-forum.com/u/Joseph_G)\ **Post date:** [February 1, 2006, 4:53pm UTC](https://www.ruby-forum.com/t/re-spring-rich-killer-rails-rich-client-proposal/99655/4 "2006-02-01T16:53:45Z")
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. ---
**Author:** ![Joseph\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ea5d25/32.png) [@Joseph\_G](https://www.ruby-forum.com/u/Joseph_G)\ **Post date:** [February 1, 2006, 5:48pm UTC](https://www.ruby-forum.com/t/re-spring-rich-killer-rails-rich-client-proposal/99655/5 "2006-02-01T17:48:31Z")
On 2/1/06, Theodore M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. removed\_email\_address@domain.invalid ---
**Author:** ![Joseph\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ea5d25/32.png) [@Joseph\_G](https://www.ruby-forum.com/u/Joseph_G)\ **Post date:** [February 1, 2006, 6:06pm UTC](https://www.ruby-forum.com/t/re-spring-rich-killer-rails-rich-client-proposal/99655/6 "2006-02-01T18:06:38Z")
Here’s some good advice for how to distribute a binary rails app on Windows: [http://www.erikveen.dds.nl/distributingrubyapplications/rails.html](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