Hi, I''ve just read some an article (http://www.jroller.com/BrightCandle/entry/oversights_in_rails_plugins_really.) This article (and the comment,) seem to imply that drb is required if running under a fastcgi kind of deployment. Is this true? Thanks, Chris. ps this is for a different server then my previous question. -- Posted via http://www.ruby-forum.com/.
On Tue, Sep 11, 2007 at 11:40:32AM +0200, Chris Williams wrote:> Hi, > I''ve just read some an article > (http://www.jroller.com/BrightCandle/entry/oversights_in_rails_plugins_really.) > > This article (and the comment,) seem to imply that drb is required if > running under a fastcgi kind of deployment. Is this true?Yes. Inspired by this post, I''ll make the :remote => true option the default in production env from version 0.5 on, allowing to turn it off when needed. cheers, Jens -- Jens Kr?mer webit! Gesellschaft f?r neue Medien mbH Schnorrstra?e 76 | 01069 Dresden Telefon +49 351 46766-0 | Telefax +49 351 46766-66 kraemer at webit.de | www.webit.de Amtsgericht Dresden | HRB 15422 GF Sven Haubold, Hagen Malessa
I just tried to post this comment several times in response to this blog post and it keeps getting rejected as spam. I''m posting it here to provide an alternate opinion to the one shared in the blog. ------------ I''m a user of acts_as_ferret, and completely disagree with your post. Aaf/ferret is a very cool full-text search solution that works very reliably in Rails when used as the online manual suggests. Jens and the team on the mailing list provide better support for it than any other open source plugin I''ve ever used on any platform. The gem vs plugin thing is debatable. I much prefer plugins over gems, since I keep all the plugins in my project''s svn repository. Deployment is much simplified, history is maintained in svn, and I don''t have to worry about gem versions on various servers. Overall, your rant shows a lack of respect for the work that has gone into aaf/ferret, and an ignorance of the benefits of using it in its current form. Certainly, nothing is perfect, and everything requires constant improvement. But, we''ve had great success with aaf and will continue to use it happily. ------------- Thanks, Doug On 9/11/07, Jens Kraemer <kraemer at webit.de> wrote:> On Tue, Sep 11, 2007 at 11:40:32AM +0200, Chris Williams wrote: > > Hi, > > I''ve just read some an article > > (http://www.jroller.com/BrightCandle/entry/oversights_in_rails_plugins_really) > > > > This article (and the comment,) seem to imply that drb is required if > > running under a fastcgi kind of deployment. Is this true? > > Yes. Inspired by this post, I''ll make the :remote => true option the > default in production env from version 0.5 on, allowing to turn it off > when needed. > > cheers, > Jens > > -- > Jens Kr?mer > webit! Gesellschaft f?r neue Medien mbH > Schnorrstra?e 76 | 01069 Dresden > Telefon +49 351 46766-0 | Telefax +49 351 46766-66 > kraemer at webit.de | www.webit.de > > Amtsgericht Dresden | HRB 15422 > GF Sven Haubold, Hagen Malessa > _______________________________________________ > Ferret-talk mailing list > Ferret-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/ferret-talk >
You didn''t mention in your post the "alternative" view - only that you believe its great but with no counter argument to the points I raised. Can you be more specific where I am getting it wrong so that I can learn. I''m coming to ruby, rails and aaf(ferret) with a brand new set of eyes, I am a noobie in every sense and if I see it wrong then I want to be told as such. The capistrano issues I raised for example were for the most part resolveable and now all they need to do is needed is capture that in the official documentation. I comment on it not to rubbish but to begin the process of fixing the behaviour in a cluster and production behaviour. Should my comments and solutions be acceptable I am willing to put my coding time where my mouth is and implement the solutions, because I NEED it for my app to be able to work properly. Its not like any of the other solutions are good either. Gem V plugin is always going to rage, I simply can''t get the plugin to work with a svn:// url so I don''t have the option to use it, which means I can''t run aaf at all because I have to have a basic cluster because rails requires it! As I said in my post if the gem is going to be published it should come with the necessary tools to get a Drb server started, it seems like a simple enough change (I hope) and one that will allow me to reenable my ferret support in my app. As for rejection as spam I don''t know what is going wrong there, I don''t even have the spam filter turned on, are you doing the maths question? -- Posted via http://www.ruby-forum.com/.
Hi Paul, please see below: On 9/11/07, Paul Keeble <csuml at yahoo.co.uk> wrote:> You didn''t mention in your post the "alternative" view - only that you > believe its great but with no counter argument to the points I raised.Your general tone was that there was something hidden and that the docs don''t tell the truth about the DRb requirement. That''s just false. The top page of the doc says to use DRb in production environments: http://projects.jkraemer.net/acts_as_ferret/wiki Single point of failure might be the only valid point you make, but people are typically using monit to make sure that if the process fails, it automatically restarts. (That''s what we do, and it works great.)> Gem V plugin is always going to rage, I simply can''t get the plugin to > work with a svn:// url so I don''t have the option to use it, which means > I can''t run aaf at all because I have to have a basic cluster because > rails requires it! As I said in my post if the gem is going to be > published it should come with the necessary tools to get a Drb server > started, it seems like a simple enough change (I hope) and one that will > allow me to reenable my ferret support in my app.Have you tried using piston? That''s a great way to get plugins for Rails, and it does support the svn:// URL: http://piston.rubyforge.org> As for rejection as spam I don''t know what is going wrong there, I don''t > even have the spam filter turned on, are you doing the maths question?I did -- several times. Each time the message said something like "your post has been flagged by our spam protection and will not be posted". Thanks, Doug
Doug Smith wrote:> Your general tone was that there was something hidden and that the > docs don''t tell the truth about the DRb requirement. That''s just > false. The top page of the doc says to use DRb in production > environments: > > http://projects.jkraemer.net/acts_as_ferret/wiki >It doesn''t actually say it''s required though, just that it''s supported. Chris. -- Posted via http://www.ruby-forum.com/.
On 9/11/07, Chris Williams <chris at nonfatal.com> wrote:> > It doesn''t actually say it''s required though, just that it''s supported.True, it says: "DRb Server for centralized index access in production environments" It doesn''t say "required", true, but I hardly think it''s worth charging the open-source code contributor(s) with "lying". Thanks, Doug
> It doesn''t say "required", true, but I hardly think it''s worth > charging the open-source code contributor(s) with "lying".My tone is irrelevent, that is just me ranting. What is important is the technical problems I faced. Consider the fact that someone doesn''t have any documentation, what would you want the code API to do? I think documenting it is a patch gap to a larger problem, one where the behaviour is not inline with the expected nor is it desireable from an ease of use perspective. Do you not agree that it would be nice not to have to use remote => true in every model AND more to the point not have to do different things in dev and production because of Drb? -- Posted via http://www.ruby-forum.com/.