Interfacing FreeCAD with Object Storage solutions

[vejmarie]

We have a Python script fcbt.py that simplifies this task a lot. It basically copies the files from the _TEMPLATE_ directory with the specified name.

Yep, I found it and it seems to work like a charm.

Hmm, from the quick look I couldn't see where the Document really needs to be touched but maybe I overlooked something.

The RestoreDocFile within the Gui/Document.cpp is making a call back to readFiles with a zipios stream as input. I tried to avoid to overload that class which is tricky with an http based API and is also a non-sense as the file structure is far away from being a zipios one. I mostly rewrote a GetEntry function for the Cloud read operation.

I made a really dirty thing within the Cloud branch (just pushed the change within it) to workaround that by adding a pointer to a call back in the case the pointer is initialized. (it is even not yet fully implemented that way). Roughly the writer could be "independant" from the zipios classes but looks like that the reader is harder to implement currently and could be needing very slight modifications.

The zipios stuff is good, but not that generic, which makes tricky to restore content in a different format (the writer side was "ok"). I might have missed something.

Regarding linux support, I believe it might be better to support snap / appimage only with all of our dependancies. It is a nightmare to rely on the distro image. That is also why I like the MacOS packaging and even the windows one, as we rely on our own build of the libraries.

[wmayer]

The RestoreDocFile within the Gui/Document.cpp is making a call back to readFiles with a zipios stream as input.

True. Here we have to avoid to do an explicit cast to a fix type. I will have a look how to make this more abstract.

The zipios stuff is good, but not that generic, which makes tricky to restore content in a different format (the writer side was "ok"). I might have missed something.

It must be checked where exactly the zip classes are directly used. So far, it's inside App::Document::restore, App::Document::saveToFile and Gui:::Document::RestoreDocFile. If needed then we could also change the former two methods and pass a Writer/Reader object as argument.

[realthunder]

It must be checked where exactly the zip classes are directly used. So far, it's inside App::Document::restore, App::Document::saveToFile and Gui:::Document::RestoreDocFile. If needed then we could also change the former two methods and pass a Writer/Reader object as argument.

Here is my proposed change. Pass a parent Base::Reader to Base::XMLReader at construction time, add XMLReader::readFiles() will no longer need an input argument, just call its parent Reader::readFiles(). I've also added ZipReader and FileReader that are derived from Base::Reader for actual implementation of Reader::readFiles().

There is one more twist (which is essential to allow splitting object content into their own XML files). Each Base::Reader can be passed a parent XMLReader at construction too. So we have a chain of Reader -> XMLReader -> Reader -> XMLReader, etc. Calling XMLReader::addFile() will only add file to the top level XMLReader. And calling XMLReader::readFiles() only dispatches files if it is at the top level. This also makes it easy to know exactly how many files are involved for a given document, since they are collected at the top level.

You can load the diff view here. The link is supposed to jump to Reader.h diffs, but It's a big diff, so may take some loading time.

I am not sure if you've read the other thread. My suggestion to vejmarie there is to use the document observer events to trigger background syncing to the cloud. We may need to tweak a little bit about the observer to allow client code abort the document saving due to, for example, cloud syncing in progress. I also suggest that we can use similar method for a version control module to bridge between FC and VC software.

[vejmarie]

Ok this is closed to what I was thinking (I mean passing a Reader object instead of a ZipStreamBuf). Let's see if wmayer agrees on it. I will have a look to the document observer in a second step, but will definitely do it. I liked to finish the basic infrastructure in a simple way. (I don't mean that the observer aspect is a complex one, but must admit it is more work on my side short term, as this is an additionnal stuff to learn ).

[vejmarie]

Just made a PR to activate the module -> -DBUILD_CLOUD , so it shouldn't break anything but will help me to move forward and get some friend working on it with me . I didn't integrated any changes coming from realthunder and found a workaround to design the reader which shall be acceptable I believe and hope. We still have time to adapt 0.19 is far away from now