It looks like much of this code would be useful for compounds other than those in the KEGG database. From what I can tell, the user would need to supply a .mol file and the molecular weight (and optionally a name and formula). .mol files are a standard that can be accessed in other databases (e.g. via webchem::cs_compinfo(csid, field = "Mol3D")) or can be created by converting from another representation like SMILES (e.g. by using ChemmineOB::convertFormat()).
I know this would require some big changes to how the package works, but there would be additional benefits to separating the KEGG functionality out of calc_vol(). For example, the main functionality of the package would no longer be dependent on the KEGG API being up and functioning and staying the same. From my experience working on webchem, APIs change or become inaccessible more than you'd think and it sucks to have your whole package be brought down because of some minor change in an API that you have no control over.
It looks like much of this code would be useful for compounds other than those in the KEGG database. From what I can tell, the user would need to supply a .mol file and the molecular weight (and optionally a name and formula). .mol files are a standard that can be accessed in other databases (e.g. via
webchem::cs_compinfo(csid, field = "Mol3D")
) or can be created by converting from another representation like SMILES (e.g. by usingChemmineOB::convertFormat()
).I know this would require some big changes to how the package works, but there would be additional benefits to separating the KEGG functionality out of
calc_vol()
. For example, the main functionality of the package would no longer be dependent on the KEGG API being up and functioning and staying the same. From my experience working onwebchem
, APIs change or become inaccessible more than you'd think and it sucks to have your whole package be brought down because of some minor change in an API that you have no control over.