Yes, that was the goal. There are only a few fields in common among the compounds I’ve seen so far, and I will probably only include the most common those and require only title and formula (in the most simple form) allowing others such as density
, boiling-point
, molar-mass
, and probably eventually something like a wikipedia link, to remain optional.
That’s something I haven’t figured out yet. I’m thinking of two different paths, and am not clear on which will be better for this project:
-
Supporting multiple editions, each with its own collection of tools, and with some interdependencies managed on building these editions, containing no project-specific plugins at all.
-
An organization into plugins, in which the equivalent of such multiple editions would involve embedding some subset of the available plugins (again with dependency tracking). With this, adding new features to a smaller wiki would usually be done just by importing additional plugins.
In either of these models, adding additional compounds should be simple enough. But to package them together and offer, say, the Organic Chemistry 101 molecules, the second model would be a more natural fit.
(And of course there’s a hybrid model, where some baseline editions have much of the shared functionality, but plugins are offered for the advanced stuff.)
I think you’re right, and I don’t expect users to be adding thousands of them. This is not ever going to take the place of online compound databases.
I’m not worried about performance, in general. The only thing that concerns me at the moment is how quickly the various versions of the periodic table render. I’ve not seen anything terrible yet, but it’s already a little slower than I’d like for the one I’m building now. Still, it’s not bad enough that I’m spending much mental effort on that; I just know that if it’s not faster once I get the full functionality, I may take a pass at that. As to capacity, I’ve had no concerns so far.
Thank you for the advice.