John, Thanks for the long answer. Well there are a lots of information there and we probably need to spend sometime time to understand it inside and out.
I am an average programmer (maybe a little better than average) and has spent last week or two opening up http://ruote.rubyforge.org/documentation.html everyday (3-4 hours a day) and comb through the document trying to learn ruote. It is a good place to start with. But I don't feel I am good enough after reading all the document (at least 2 times) to start coding comfortably knowing what I am doing exactly. Probably it is like that when learning new tricks in programming and we learned rails pretty much the same way. For rails there are large number of programmers and help/document are easy to come by on stackoverflow.com or online. For ruote, the community is much smaller and the document other than yours is hard to come by. It seems that most of time you are the person answering the questions and it certainly wouldn't be easy for you or anyone else. There is another member on our team who has integrated ruote-kit within a rails engine a year ago. He like ruote and said it was very stable. But about why and how he did this not that, he could not have the answer easily as he did it a year ago with a test project.This time we are looking into integrating ruote directly into rails without going through ruote-kit which is an extra layer and uses haml and sinatra (we use erb and rails (rails engines)). If you don't mind, I would like to post the question and your answer to stackoverflow so the answer will be available for others who want to know more about ruote. It is a quality piece information from the author of ruote and is worth to keep. Best Regards -emclab On Thursday, June 20, 2013 8:29:22 AM UTC-5, John Mettraux wrote: > > > On Thu, Jun 20, 2013 at 06:00:11AM -0700, emc_lab wrote: > > > > In answer#1, you mention workers outside of rails app. Is there any > > document or post explaining workers outside of an app (vs inside)? There > is > > a snippet of code for workers outside of rails app in ruote document. > But > > there is no explanation of what it is and what kind of impact it has on > the > > app. > > Hello, > > it's a bit discouraging to read that after having written lots of > documentation. Is it my fault? Or is it your fault because you can't read > between the lines? All the time I invest in helping you, it will never pay > back. I give you precise help, you make vague affirmations about a "ruote > document" that exists somewhere and talks about worker outside of Rails > apps > (can't remember writing it)... > > Anyway... > > To run workflows, a ruote engine (one could say a ruote system) has to > have > at least one ruote worker running. > > Ruby on Rails is used to build web applications. When it was a baby > framework, Ruote on Rails was running on top of Webrick, a pure Ruby web > server. Nowadays, there are many web servers to run Rails on top of. > Mongrel, > Passenger, Puma, Unicorn, ... > > Some of them fork Ruby processes while other use threads with a single > Ruby > process, etc... Many choices, many sets of pluses/minuses. > > What if you run a ruote worker inside of a Rails app? Well it steals some > of > the resources of the rails app itself and the response time may go down or > not. If the Rails app is run on top of a forking server, you may end up > having one ruote worker per Rails app fork, etc... > > Running ruote workers externally to the rails app has its advantages, as > said, ruote doesn't eat Rails resources (if we make a parallel, with most > of > the database servers, your client doesn't run background indexation work, > your Rails app isn't running indexation work, etc). > > Some web servers Rails run on, can go in some "quiet mode" when no process > is > running (a new one will be spawned if the need arise), that means that if > you > rely on such a web server and your run the ruote worker inside of the > Rails > app, you could have times when no ruote worker is on, it shouldn't too > bad, > expect when using schedules: if there is a timeout or some work scheduled > at > time t and at that time there is no ruote worker, the work will not happen > {on time}. > > Should I write documentation for all of this or should I expect the people > integrating my library to know that beforehand? > > Are you entitled to such documentation or am I entitled to believe you > [want > to] understand what you are building? > > > > Also any document or post or open source project which may help us to > > better understand ruote and its integration with rails are appreciated. > > In order: > > * http://www.ruby-lang.org/ > * http://rubyonrails.org/ > * http://guides.rubyonrails.org/ > * http://ruote.rubyforge.org/ > > > Best regards, > > -- > John Mettraux - http://lambda.io/jmettraux > > -- -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en --- You received this message because you are subscribed to the Google Groups "ruote" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
