The Road to deninet 6.0: An Idea is an Idea, is an...
I have been thinking a great deal lately about what do to about the Idea Database. After the long drive to complete the new Windowlight theme (now up and running on the site), this core feature of deninet 6.0 hasn't received nearly enough attention.
When I originally set out to recreate the system we had under deninet 5.0h and earlier, I'm confronted with two basic strategies. The first is to search throughout the Drupal module repository and attempt to find a solution that would create the necessary facilities to meet the original spec. The second is to write our own module from scratch. I've dabbled in module creation before, but ultimately found the projects I was going to undertake too complex or unnecessary.
Relying on contributed modules does have some serious advantages. Instead of a development process, the effort becomes largely that of configuration. Once the possible methods have been reviewed and compared, the list of possible methods can be reduced to an acceptable solution. After that, it's only a matter of implementation and adjustment to the new features and consequences. I've reviewed a number of modules that could possibly work, but the only one that met expectations was the Node Comments module.
Node Comments is unique in Drupal as it replaces a bit of functionality provided by the core product. While Core Comments is packaged as a module, it is such an essential component that it is a dependency of several other modules. While this would provide a functionality similar to what I was hoping to achieve for the Idea Database, it affects a larger swath of the site functionality than I would prefer. Taking this option would have some serious drawbacks.
For that reason, I've been investigating creating a module to implement the functionality. How to go about doing that, however, becomes a discussion in of itself.
The module could be developed in one of two ways. It can be created as an integrated, drop-in solution that would provide everything necessary in order to function. It would be an "Idea Database" module in the truest sense. This has advantages of integration as well as being a contribution to the open source community. It would be easier to implement add-on modules to enhance functionality later (Idea sponsorship and donation). The other method is to write modules only to implement features in a generic way. Instead of an iidb module providing Idea and Thought content types, there would be a "revision review" module that could attach to any CCK type. This would be more generic but would certainly implement the Idea/Thought topology originally drafted in the spec.
There is a line of thought that suggests if something is part of your core business, then you should develop it in-house. You shouldn't trust it to third parties that may not be in line with your vision. The Idea Database is part of what I consider as the core business of deninet. If it's really so important, shouldn't it be written in-house?
The problem, as ever, is time. Developing any sort of module takes a degree of time and effort that I could be putting toward other pursuits such as Paper Girl. With my time and energy limited as they are, I'm concerned that this "simple" module would require a lengthy development cycle.
At the moment, I haven't quite decided what to do. The clock is ticking for this years DOR submission, and I would not want to opt out if at all possible. It may be best for me to let the issue of the Idea database to sit for a while I work on my DOR submission. Perhaps the time away will give me some perspective.
