Aaf requires drb?

Hi,
I’ve just read some an article
(Best Online Casino in Australia | Top Licensed Casinos for Gamblers)

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.

On Tue, Sep 11, 2007 at 11:40:32AM +0200, Chris W. wrote:

Hi,
I’ve just read some an article
(Best Online Casino in Australia | Top Licensed Casinos for Gamblers)

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
[email protected] | 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

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?

Doug S. 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.

Hi Paul, please see below:

On 9/11/07, Paul K. [email protected] 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

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?

On 9/11/07, Chris W. [email protected] 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