I have released the first versions of both of Content Recommendation Engine and Similarity Objects. These modules, while appearing to be duplicates of other modules, are a significant departure from them. Most notably, there use of Views 2 and thus, respecting node_access() which is lacking in most of these modules or it is done after the query is sent to the database. Please read on to find out why I believe both these module provide more functionality then anything like them.

Similarity Objects
The Similarity Objects module is the first module that I have found that provides similar node blocks and respects node_access. Furthermore, it is the first module of its kind that integrates tightly with Views 2.0. It provides a way to have multiple similarity calculations happening allowing a site to provide a similar blog posts section and a similar pictures section. And each section can use different methods to generate their similarities. Say the blog posts section uses term similarity where the pictures section provides a voting based similarity.

I plan on integrating tightly with the Recommender API module. Dan and myself had productive talks at Drupalcon and we both agreed upon an approach. Basically, the similarity objects will allow selection of algorithms, which include the basic cosine, provided by similarity module and any other algorithms that the recommender api provides. This is coming soon.

The Similarity Objects module is actually designed to provide similarity calculations for much more then just nodes. I plan integrating it with user similarity calculations and term based calculations. Conceivably, that would allow for a site to have a "Suggested Friends" section where the similarity calculation is based off of friend relationships. The potential for this module is pretty amazing.

I am also looking for a bit of guidance. In this module, I made a rather interesting design decision which is best described with a simple example.

The similarity object calculates that node 14 and node 2 are similar to each other to the .75 degree. This similarity will be stored in the table by INSERT INTO TABLE (nid1, nid2, value) VALUES (14, 2, .75). Basically, it stores exactly one record of this relationship. This makes query for that data a lil hairy as a similar node could be nid1 or it could be nid2. So within this module, there is logic both in the Views layer and the block layer to handle this.

So my question is there any real benefit to just storing the relationship once? Is it better to double the table size to speed up the query? What is the best way to measure this? Has anyone else faced this issue?

Content Recommendation Engine
This is where things get more interesting. The goal of the Content Recommendation Engine is to provide a personalized content recommendations. My very first stab at achieving this did not scale well at all. It did the calculations on the fly and it slowed down voting process by saving similarities every time a vote was cast. Now the 6.1branch, the similarities are handled by the Similarity Object module. And now the recommendations are cached in a separate table, speeding up the query immensely. And because the recommendations are cached away in this table, the Views integration is very easy to write. So it now integrates exclusively with Views 2, providing all that goodness that comes with it.

I really excited about both these modules. They are a culmination of several years of Drupal development and experience. I have tried several different directions of the past several years, trying to find something that I believe would scale and I feel like these two can achieve that.