Concept Of Design
- Version management see:
- User interface
- Database
- Used programming language
- Attributes
Version management is a difficult topic. A main issue is that it should be able to create releases of every individual part, assembly (and optional drawing.)
There are serval different (Open source)version control systems available. The main difficulty is that those are most written for software. Where software is released as a whole that is not always the case within the mechanical world. see: @ref to story Note Grd: But there are also closed source versions. I think that we should also accept those because in a company they might only allow this kind of software. This has to be tackled. Currently the most promising implementation is the svn version system (a Client-server). The most well known Distributed version systems are git and mercurial. Note Grd: Why does it need to be tackled? You can also allow them all. But in that case we need to have an admin page in where we can select which one we use. They all work roughly the same, but we need to make all work of course. But we are gonna start with SVN.
Note: We have to decide if the model(part / assembly) gets an update, the drawing get also an update. The same issue applied in revers order. Note grd: This is never gonna work. When a part is changed you aso need to update the drawing of that part, the assy (or assies) in where it belongs and the drawings of those too.
Within databases there are two main types of databases. SQL based databases. Examples of SQL like databases are SQLite, MariaDB, PostgreSQL.
The other is noSQL. An example of this database is MongoDB
Note: Add What the difference is and how such a database is build up
Note Grd: Why do we need such a database? That is the question. We need it because we can't extract the relevant information out of VCS and that is because a FC file attributes are stored somewhere into that file. And you want to be able to search that metadata information. To be honest, I don't care about which kind of software you use (SQL / noSQL), but SQLAlchemy helps a lot when you use SQL data. That is why I think that we better use SQL. Starting with sqlite.
For the user interface there are two main issues but both are related. the issue about the programming language is described below. What i mean with the figure above is that there are two main options of interfaces.
- Web interface
- Local stored interface
Looking at the web interface has some pro's and cons
| Pro's | Con's |
|---|---|
| Centralised updates | Security is more difficult(specially .js) |
| More easy to add other SW | More data transport |
|
(Maintainability?) | (Maintainability?)
See also Comment of user1234 in the related topic
Looking at the local storage there are two tastes available(for now).
- A in-depended tool
- inside FreeCAD (for example Add-on manager)
- If Using the Add-on Manager see: the Workebench start kit
- Another important Thread about the Add-on Manager Redesign
Specially the Add-on manager can help for at least (semi-)centralised updates.
Note: How does the GUI interact with the user?
In case of the web interface can be programmed with for example Javascript or python (there are more but these are most well known).
In case of a local program Python can be a good option too. This is also because it works good together with FreeCAD and so the FreeCAD Add-on Manager. What are pro's cons of the Add-on manager:
| Pro's | Con's |
|---|---|
| Semi Centralised updates | Not direct integration |
| Fast(er) update speed⁰ | python only |
| Translation to other languages | More difficult user handling |
| Maintainability |
⁰ Faster is compared to FreeCAD when every chance goes through checks(Except when WMayer fix it).
What i meant with user handling see story later on
By using the add-on manager it is possible to change quickly when a change / update is needed. _Note: We have to decide to:
- Make a FreeCAD Add-on
- ?_