Explore persistence of scans

[rye]

Each scan dump includes a result by plugin 19506, which includes information about the scan.

I should build some more smarts into the scan importer that is based on this plugin.

This kinda parallels my idea of having a persistent cache locally, with something like a SQLite. (Wow, #19 again?) This kind of a change will require a bit of rearchitecting of the overall design of this thing… we need to first load rows and then process each row post-import.

• [ ] Move CSV importing into its own module (row-wise imports into a row-space)
• [ ] Add custom handlers for special plugins
• [ ] Figure out a way of looking up scan results by plugin ID in O(1) time (Hash lookup)
• [ ] ...

[rye]

Still like this idea.

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.