I think the current importing model could more or less get scrapped, actually. Most of the directory structure can just get nixed, and what we're left with is a nice barebones starting point again.
It's slow, it's bulky, it's wasteful, and it has some serious design flaws. It's hard to extract data from it as it stands currently.
Taking lessons from the current iteration, the following goals are apparent:
Nessana should provide visual feedback while it is doing work, because the dumps are large.
Nessana should provide a robust system for filtering out results that are unwanted.
Nessana should be implemented with TDD. If you don't know how to test something, self, you should look that up before implementing it, or mock things as straightly-forward as possible.
Nessana should maintain a persistent cache of what it knows about. This information could be updated separately via an import script or something.
Seeing as how the reimplementation will be a bit tedious, two separate streams of development might be required. Propose the use of branch next for the development on this new version.
From #38:
Seeing as how the reimplementation will be a bit tedious, two separate streams of development might be required. Propose the use of branch
next
for the development on this new version.