Quote:
Originally Posted by Starson17
I've noticed that this thread is in Library Management, not Plugins. Duplicate finding strikes me as a universally desirable function, not something that only a few people need. It's also more likely to be used by the new user, who's cleaning up the newly (badly?) entered data, and who may be intimidated by the steps needed to get a plugin installed. I don't spend much time in the plugin subforum, but is there any written criteria for what should be a plugin vs. code enhancement in the trunk?
|
I think that this 'project' could have two distinct phases in its life-cycle. The first is discovery: what needs to be done and how should it be done. This phase is best done largely in a plugin with API support as needed in the trunk, for even faster turnaround than weekly. The second phase is maturity: this phase concentrates on performance enhancement, discoverability, documentation, and tuning. The code could move to trunk, and perhaps should.
One issue that affects the choice is whether or not the code will be hacked by a significant number of people. If so, it should remain as a plugin. I can see this happening if people tune matching algorithms to their situation. Of course, the presupposes that a person has that ability. Many do, but many more do not. It may be that test functions themselves become plugins, while the framework migrates to base functionality.
Another issue is Kovid's view of the future. I have no idea how he feels about all of this.
Charles