We should be wary when straying outside the OPENSCAD API. Obviously, we want all the cool functionality that others are contributing but how to organize the API is still being realized. As this library title implies, this is SCAD-API.
Shall we continue expanding the API?
Shall we make new API libraries?
Shall we allow others to create and maintain new libraries at JSCAD?
By the way, there are some really cool OPENSCAD libraries available, like the Poor Mans Screw library at iThingverse. It would be great to be able to support some of these at JSCAD.
Good poiunt @z3dev , this is very important indeed:
I think it is essential to keep things specialized :
csg.js api needs to remain minimal
this repo should be ONLY for the Openscad like syntaxic sugar
should we have something like a 'jscad-extras' repo ?
we need to have a way to import arbitrary libs of parts into jscad from the UI (I am experimenting with this)
I think only the 'core' libraries and applications should be in the jsad namespace (this org), but we should encourage the creation of new specialized libraries
We should be wary when straying outside the OPENSCAD API. Obviously, we want all the cool functionality that others are contributing but how to organize the API is still being realized. As this library title implies, this is SCAD-API.
Shall we continue expanding the API? Shall we make new API libraries? Shall we allow others to create and maintain new libraries at JSCAD?
By the way, there are some really cool OPENSCAD libraries available, like the Poor Mans Screw library at iThingverse. It would be great to be able to support some of these at JSCAD.