While implementing support for Cloud based import/export of Documents using App::Link I am hitting a limitation, that I liked to discuss with the community.
Currently everything is implemented within the Cloud Module (user account setup, Reader / Writer class expansion, and python interface).
As to support restore of Document which contains Cloud based entry which replace filename by a URI (aka something like https://localhost:443/<document_name
>), the App::Link object needs to know how to read such "file". Right now it relies on App objects standard reader, which knows only local file storage. The URI approach is known by the Cloud::Reader object which is sitting into a module, that I can't use, as it is a cycling dependancy.
I have 2 options (maybe more, but this is why I would like to open the discussion).
- Either keep moving forward with the Cloud workbench as it is, but in the case of a link save/restore operation, everything will be done by the Cloud module. I believe I can manage it, by a basic "hack" which will parse the Document.xml file to identify all Links XML entry, and open the missing Documents locally before sending the Document.xml file to the interpreter and traditionnal App::Link workflow. In that case, as all pointed Document will be soon opened, it shall work. The save phase will be easier, as App::Link do not save attached Documents. This approach has a strong limitation it doesn't allow to link local and remote storage document, or to save the Document which contains the links locally. Everything will be remote.
- The other option is to integrate the Cloud object, into App. This could allow to mix everything, and handle local store operation. The App::Link will handle everything regarding opening associated Document, and could learn how to handle URI file name.
Any other option you might be envisioning ?
Option 1 seems easier for me to implement short term. Option 2 requires to integrate part of Cloud workbench into FreeCAD core, and move user credentials management into it.
Let me know what you think. I am currently thinking at moving forward with option 1 assuming that the limitation is not going to be a showstopper, but still might be perceived as a weird behaviour. When option 1 will be done, and stable enough, I might be moving to option 2 of 0.20/0.21 ?