chennes wrote: ↑Sat Feb 04, 2023 7:04 pm
Next up we discussed some more far-reaching future possibilities, led by Kurt (@kkremitzki):
- CAD Web stack based on ideas from Post GIS
- Adding PyKDE to the PySide imports
- Rewrite critical parts of OpenCASCADE Kernel in ... Rust?
- Rust is polarizing - what about Nim?
Fleshing this out a bit as I kinda rushed through things trying to let everybody go to lunch:
CAD Web Stack
QGIS is a sort of cousin application to FreeCAD, being a cross-platform Qt-based app for a deep technical purpose: geographic information systems & modeling.
It supports several remote backends. One of those is PostGIS, which is a PostgreSQL extension providing geospatial data types and operations. This spawned a whole ecosystem:
- Spatialite is similarly a DB extension, but for SQLite, which replaces a database server with a simple file, so you get the power of a DB without the network round trip
- Wrapping these spatial DBs is e.g. GeoAlchemy, based on SQLAlchemy, a Python SQL toolkit and object relational mapper
- One level higher, geospatial web apps and services can be created by GeoDjango, an included contrib module in the Django Python web framework
So, there's a whole software ecosystem spawned by PostGIS. Why not a PostCAD, OpenCASCADE-powered CAD data types and operations in PostgreSQL? By turning the DB into a CAD application server, we can use FreeCAD as a client to a more powerful machine. There's also the huge feature set of these databases: for example, access control, centralized authentication, deduplication, transactions, replication, and more.
PyKDE
Wouldn't it be nice if people could focus more on CAD development in FreeCAD instead of needing to be UI/UX designers? We already rely on Qt as an application framework. The KDE Frameworks are a set of 83 add-on libraries for programming with Qt, which would take care of a lot of our non-CAD concerns.
However, FreeCAD already groans under the weight of its dependencies. Adding in KDE deps would be asking a lot without already having the thing you're trying to make. Instead, we can look to PySide, the Python bindings for Qt. This allows us to interact with FreeCAD's interface dynamically, avoiding the need to add or change C++ code and recompile.
Similarly, there have been a few abandoned efforts at a PyKDE, providing the power of the KDE Frameworks but in a form that could be more easily distributed as a workbench instead of requiring core FreeCAD changes, at first. I was able to take the most recent attempt, PyKDE5, and basically dust off the cobwebs and run a demo app. Would it be worth going further?
I discussed this with some of the KDE people at the Ubuntu Summit, who helped me on some possible funding sources for this sort of project, but for now, to be continued...
OpenCASCADE & Rust
OpenCASCADE is sort of the elephant in the room when it comes to FreeCAD's functionality & reliability. Similarly, there are rumblings about the long-term fate of C++ and its possible replacement by Rust. The argument, in short, is that about 60-70% of browser & kernel bugs are caused due to memory-unsafety, and Rust can provide guarantees about entire elimination of this class of bug.
See this publication on the topic by Consumer Reports, previously known for winning the fight to have car seat belts and exposing the danger of cigarettes.
However, attempting rewrites for software is generally fraught with peril, and the idea of replacing OpenCASCADE wholesale is of an absurd scope.
How could incremental progress be made?
The Data Exchange module of OpenCASCADE is used for file format support, or in other words, ingesting untrusted data. If a Rust implementation of Data Exchange could be produced, it is something which could be useful on its own, even if that project went no further.