Concept Of Design
The hierarchy is described from left top to right bottom.
The Test cases are currently a set of CAD-files so that are needed to test the behaviour of reading properties from it.
Other behaviour is mainly described in the workflows that are worked out in the workflows folder.
Both depends on the requirements.
Right in the top are the libraries. In this case Software Libraries.
Second row in the middle there is the domain.
The domain is where where the system acts in.
Part of the domain is are the actors(This can be other systems but also persons).
Another part of the system is the structure (of the system).
Inside the system there are some (potential )sub systems.
Be aware that within this context the Ldap-server is part of the Version system.
Beside the side packages FreePDM is spit between a Frond-End system and a Back-End system (See image above). The Frond-End is installed on the Client-PC, while the Back-End is installed on the Server(see image below).
Currently the Server is an abstract object. It can be:
- A physical Device
- A virtual Machine
- A container
- A combination from above
For a more Container like environment see: Container
One of the requirements is that it should be possible to run a server with a limited amount of extra hardware. Of course this holds only for small environments! For a few user this should be work in a Virtual machine or a Raspberry Pi but for more users this is probably not powerful enough!
An extra Item could be Raspberry Pi cluster this DIY project or the Tuning Pi.
The Database is the only real prerequisite. All Other Frameworks are not directly needed.
There are multiple options on what type of Database is preferred. A list of (currently )optional Database can be found in the Design Decisions. The question with these Database options is if they conflict with the webserver.
For more information about potential Database tables see: FreePDM_07-DatabaseSetup
Somehow the functionality of the LDAP-server is difficult to grasp.
Or the idea of a svn-server sounds way simpler.
Beside that it sound more easy a svn-server has some drawbacks.
Both svn and git aren't good in handling Binary Data.
Simply described they just make a copy in the background.
A git / svn versioning system work on project level.
So a project contains a set of Files and the set of Files (as a whole )get a certain Version / Revision.
While in CAD-Data it is quite common that not all CAD_Files have the same version number.
That a single File needs a change or even that only the Drawing needs a change.
How does the LDAP-server work:
Imagine yourself that the LDAP-server is a Database in the form of a file structure / Folder hierarchy.
It handle User authentication on File / Folder level.
But is don't handle versions as what a versioning systems does.
This means the versioning part should be done between the LDAP-server and the Database-Server
Main reason why the LDAP-server is currently optionally is that it is unknown if this kind of hierarchy can be achieved from the Database alone.
In DB Versioning Update is already written about the LDAP-server. If you want to dive deeper you have to look there.
However the webserver is currently not wanted see Design Decisions.
If in the future there is a reason to add one.
It is good to dive into it including the set of optional solutions.
Therefore an overview is created with the currently available (Python) Web-Frameworks including how they potentially interact.
The colors are a bit shiny, but it is what it is. Because all lines become a bit spaghetti like the lines of the colors are changed to the same color as the needed middleware.
A (sub)set of available python _Web Framework_s:
- Bottle
- Django
- Falcon
- Paste - pythonpaste.org is not accessible anymore.
- Pyramid and Pylons Project
- Webpy
What is the best option for a Web-Framework?
Is bottle suitable for complex applications?
Bottle is a micro framework designed for prototyping and building small web applications and services. It stays out of your way and allows you to get things done fast, but misses some advanced features and ready-to-use solutions found in other frameworks (MVC, ORM, form validation, scaffolding, XML-RPC). Although it is possible to add these features and build complex applications with Bottle, you should consider using a full-stack Web framework like pylons or paste instead.
What about Pylons? It is now pyramid
Maintenance-only mode
The Pylons web framework has merged with repoze.bfg into Pyramid, and is now in maintenance-only mode. You may submit a pull request or issue, then respectfully request of the maintainers to accept it and make a release.
It's highly recommended that new projects start with the new merged web framework, Pyramid.
Paste has some difficulties according them selfes:
Paste has been under development for a while, and has lots of code in it. Too much code! The code is largely decoupled except for some core functions shared by many parts of the code. Those core functions are largely replaced in WebOb, and replaced with better implementations.
The future of these pieces is to split them into independent packages, and refactor the internal Paste dependencies to rely instead on WebOb.
Webob is part of the Pylons Project.
Quotes from Django install page.
If you want to use Django on a production site, use Apache with mod_wsgi.
If you can’t use mod_wsgi for some reason, fear not: Django supports many other deployment options. One is uWSGI; it works very well with nginx. Additionally, Django follows the WSGI spec (PEP 3333), which allows it to run on a variety of server platforms.
So if using a production environment what FreePDM is meant for we should use a Apache or Nginx environment.
What databases are supported by what environment. First the standard _Framework_s:
- Apache - FreeTDS, MySQL/ MariaDB, Oracle, PostgreSQL, SQLite2 / 3, ODBC
- Nginx - Almost None Information...postgresql (excl third-party databases)
- lighttpd - dbi, ldap, mysql, or postgresql
- xampp - MariaDB, others are unknown
There is a big difference between the packages above.
Nginx is probably the most difficult one. Not technically but it has a difficult interaction between the open source package and the paid(don't know if it is closed source) version.
For example there is no way how to find out what Database types are by default available.
Apache, Nginx and Lighttpd have the possibility to work together with an ldap Database.
However, at the moment, it is unknown if the Nginx has this by default.
Python _Framework_s:
- Django - PostgreSQL, MariaDB, MySQL, Oracle, SQLite (excl. third-party databases)
- Pyramid - ZODB, Alchemy
- Falcon - None, but works via SQLAlchemy
Django is the only one that has direct support for one or more Database types. Pyramid and Falcon use SQLAlchemy as middle men.
When looking at the environment this can be described as a working site.
Within this context it is important that the is a state of stability.
Currently the Apache Web-Framework looks like most developed and stable Framework.
Nginx comes close but because there is a lot less information available it is difficult to see what state is has.
The first choice should be Apache and adding Nginx later on as a valid alternative.
The most well developed Python Web servers are Django, Pyramid and Falcon.
In the python environment all are equally mature.
The main difference is the size of the Framework.
Pyramid and Falcon are much smaller than Django.
Django and Pyramid support a ldap system. Falcon maybe not.
- Full stack python Apache
- Full stack python Nginx
- Full stack python Django
- Full stack python Falcon
- Full stack python Pyramid
- Python basics Web frameworks
The Backend is the core of all functionality.
The Backend communicate with the Database, FileSystem / LDAP-Server (Optionally), Web-Server(Optionally).
Currently there is a split between the Front-End and the Back-End.
In short the Front-End handle much the UI from User Perspective. And the Back-End handle much more the interaction and communication between the Data / Database, File( Version)s, Security / Cyber Security and optionally Web-Server.
An example what the Back-End does is when user needs all files that are part of an Assembly. The user call the assembly and the backend give all lower level files.
For the install script there are probably 3 versions needed
- Linux / OSX version
- Windows Version
- Container format
For linux and OSX a Bash script would be the best option. For windows are Cmd-Prompt or PowerShell the options. For the _Container_s a script need to be created that work out of the box.
As visible it should be possible to run FreePDM from a Container.
In the figure above it is just a single Container however there shouldn't be a reason to run multiple _Container_s for different sub-functions.
If a container method is used it should work on Linux, OSX and Windows.
See here for alternatives for Docker(the most well known version).
The _Container_s could be:
A container has some drawbacks. When a container is stopped and a new one started there is a risk of losing information. More information.
In the ClientPC Block it is assumed that the user is a CAD user because it is the most complex case (see image below).
If the user is a project manager (who does nothing with CAD, even not viewing) he / she shall mainly check / change the (project )attributes.
In such a case there should be a method to install FreePDM without FreeCAD.
All CAD related features are not necessary either so this package should be compacter as its CAD Equivalent.
For Both The CAD User and the NotCAD User there are two types of accessing the FreePDM:
- Stand Alone (Preferred Method)
- Web Interface
Both of the cases should work within / together with FC. This is possible since FC make also use of the Qt WebEngine (for example the Start Workbench).
The local File storage handles all files that a user need. This are the CAD Files, but also related pdf files etc. It should be possible to have multiple Workspaces so that not all files are removed when another Project / test is needed. Both the Front-End and FreeCAD are connected to this FileStorage.
The Frond-End and the FreeCAD Add-On are the same in this case.
A big part of the Front-End handles Files So downloading the Files from the server.
An extension of the example in Back-End.
A user has called an Assembly and Downloaded that one in his (Brand new)Workspace. He Opens the file from the Front-End it should automatically download all required files in his Workspace.
More information about workflows can be found in UIInteractionFC.
Within FreeCAD Some functionality need to be added so that the files can be Checked-In or Checked-Out from a Menu or a FileObject.
On the other hand FreeCAD Needs Access to the File location, without any interactions between the different workspaces!
Current Implementation ignores the LDAP server.
Still it looks like best method for the future.
But also it adds an extra layer of complexity at the current stage!
Another note is added about projects see SVN Project Structure
An important Architecture part that is forgotten to describe is User Interaction.
The part how Users interact with the software is written on high level in FreePDM_02-Workflows.
The problem with this is that it currently ignores:
- What users have access to what information.
- What Users have when Roles / Rights for:
- What projects
- Libraries
- ...
- Is it possible to handle multiple organisations(where users have different roles per organisation)?
- etc
Now a database System structure is created in Libre office Draw. A lot of tables are drawn. With the use of arrows there are relations are shown between the different attributes. The green tables are the tables that are used first the others are implemented later. For testing purposes the initial two roles are:
- Engineer (The engineer can do everything)
- Viewer (Can only view information)
Be aware that this is a subset of all (future )existing tables. In DatabaseSetup there are listed a lot more but these are not important to this example.