acts_as_taggings : plugin vs gem

I asked the following question on the Ruby on Rails list:

I have gotten acts_as_taggable to work for a test application as documented on taggable.rubyforge.org

I am following Chad's excellent examples in ROR Recipes Beta book.

I have a few questions and hope that Chad or some other expert can help clarify them.

1. Why is the book suggesting to use taggings table instead of tags_contacts, as mentioned on taggable.rubyforge.org?
2. How can I use this taggings table instead of my tags_contacts?
3. How can I store additional fields such as member_id in the tags_contacts table or taggings table?
4. When I follow Chad's example on my Favorite class, (with tags_favorites and taggings table created) I keep getting the NoMethodError for "tag_with"? At first I thought this may be because I am using taggings table but then when I created tags_favorites table the error persisted.
5. I finally used the tag method as described on rubyforge.org and it works. So my question is, is tag_with a typo in the book or am I missing something?
6. Why does the following output say @new_record=false even when the record was created? Is it to prevent further entry of the same record?

The following are the responses by list members:

Michael Yacavone said:

The acts_as_taggable in the ROR Recipes book uses the _plugin_ written by DHH, not the _gem_ on rubyforge. Unfortunately, the plugin is not documented outside the ROR Recipes book right now.

Until DHH documents the plugin we're going to have dozens or hundreds of messages of confusion like this. Even then, the namespace collision will provide months of amusement.

To my surprise, David Heinemeier Hansson (Yes, DHH) replied:

Now here's the truly wonderful part of open source: Creator, maintainer, and documentor needs not all be caps on the same schmoe. Thus, if you find something useful, say a plugin like acts_as_taggable with the creator stamp DHH, you can choose to express your gratitude through one of the other caps.

That may be a patch to extend or it may be a tutorial about its usage or even READMEs and RDocs for the source. So try not to assume that creator equals sole maintainer or documentor. Only try to understand the truth: There is no vendor.

Michael replied back saying

I am actually trying to get a grip on this to help, which happens to be challenging for my skill level.

But when the top dog of Rails creates a namespace clash with a well-known gem, it sure would be nice to have some leadership and not defer to the magic of open-source community to sort it out eventually. Better to just say, "We're up against a new product release, and will get to this someday soon," or somesuch, which is probably pretty close to the truth.

Thought experiment: If someone else had released a plugin with the same name as a well-known gem, would the community have accepted it, or would they encourage the creator to change the name to avoid confusion? I assert that 1) the creator would have been encouraged to change the name, and 2) it is because DHH is the creator this didn't happen.

Of course, let a thousand flowers bloom, just don't expect this question to go away anytime soon.

And then

I have written a weblog entry which hopefully clarifies the situation as I understand it, and will eventually hit the Google index for future queries.
http://www.notio.com/2006/02/rails_acts_as_t.html

David then replied:

>" But when the top dog of Rails creates a namespace clash with a well-known gem, it sure would be nice to have some leadership and not defer to the magic of open-source community to sort it out eventually.

Namespace clashes are problematic for packages that wants to be used concurrently, not for alternatives. How would the situation have improved if I had called it acts_as_polymorphically_taggable (except for making jokes about such a terrible, terrible name)? Would we not have had the same questions as to what does what and why? Of course we would.

In any case, let me summarize the difference quickly. The main difference is not plugin vs gem, but rather that my version of acts_as_taggable is designed to work with multiple classes. So a single tag can be used in the tagging of multiple classes. This requires polymorphic associations and join models, which is why it only works Edge Rails (and will work in the forthcoming 1.1).

So if you need that feature, tagging of multiple classes with the same tags, then use my version. Otherwise, the old version is probably better. It's certainly more feature-rich and better documented.

My thanks to David and Michael for their clarifications.

Frank