The Collaborative Cook

I've been thinking about project ideas for HackDay over this past weekend. I've managed to come up with two ideas so far, one very useful but also very boring and one mostly for fun. I'm not sure if I'm going to take either of them any further at HackDay as I really don't know what the event's going to be like. I'm tempted to turn up and go along with other peoples projects to get a feel for the whole thing. Either way, I think the projects could be quite good so I'm recording them here for future reference.

Project One: Object Cache Item Removal Plugin for Symfony

The name could be improved, yes, but I really can't think of anything better which gets across the intent as well. The point of this plugin would be to automatically remove items from the object cache (as apposed to the config cache etc) when the Propel objects on which they depend change. At the moment if you use the caching functionality in Symfony you have to remember to drop all the relevant cache items when changing a particular Propel object. Although this gives you the most flexibility it's also quite a lot of work and opens up the possibility for some pretty nasty 'stale data' bugs.

The basic structure would include something which watches objects coming out of Propel and determines what an action / partial / fragment / whatever is dependent on, something which manages these dependencies, and then something which drops all dependent cache items when one of the dependencies is changed.

After thinking about the idea for a while I've come to realize that it's going to be quite tricky (although I don't think impossible). The problem is the range of rules for removal. Below I have listed the ones I have come up with so far. I have used a recipe site scenario for examples. The recipe site consists of recipes which have one creator, multiple ingredients (in a many-to-many relationship) and multiple method steps (in a one-to-many relationship).

Extracted objects

A cache item is dependent on all Propel objects which are accessible within it's scope. For example, a 'recipe details' action would be dependent on the recipe, the recipe's user, all the ingredients related to it and all the method steps related to it. This is the most basic rule.

Relationships

A cache item is dependent on table references between Propel objects. For example, a 'recipe details' action would be dependent on all recipe ingredients and method steps which relate to the recipe concerned. This rule handles new recipe ingredients and method steps being added while not affecting existing ones or the recipe.

Whole class

A cache item is dropped when any object of a particular Propel class is saved. For example, a 'most popular recipe' action would be dependent on any recipe rating object, so if any change, the item must be dropped. There could be a number of variations on this rule such as only kicking in on newly created objects (for a 'newest recipes' action for example) or only relating to a particular field on the object.

I am sure there are other rules which I have not thought of so I would want to write the plugin with an extensible rules architecture. I think this would be an incredibly difficult project to get exactly right but I also think it could be a very useful one, if it is done right.

The Collaborative Cook: A Recipe Orientated Wiki

This is the more fun idea, the title says it all really. There are two main angles to look at here, collaboration to correct mistakes and add information on a recipe which is pretty much the same as regular wikis, and then there's the idea of collaboration as a creative process to create new recipes together. The second angle is one which I think is much more interesting. It would need to handle branching very well so that recipes could be developed in different directions. It would also benefit from a way of merging two branches together if it turns out they are going in the same direction. I think lessons could be learnt from the collaborative storytelling sphere for this side of things.