Talk:OSE Collaboration Protocol

Andrewusu's thoughts on FreeCAD git integration

FreeCAD v0.17 and newer

As of FreeCAD version 0.17 the WebTools Workbench allows Git integration through manual steps.

However *.fcstd files are binary files, specifically zip archives, and binary files aren't really suitable for version control tools like Git.

To prevent the explosion in space usage this mal-use would cause, a git filter should be set up for these *.fcstd files, such as:

1. costerwi/rezip, But requires Java JRE 8 or newer...
   1. hoijui/ReZipDoc Open Source Ecology Germany, requires JRE 8 or newer writeup
2. callegar/Rezip, written in bash, won't work on Windows (unless cygwin is used)
3. Zippey, written in python, appears to be less optimal than the other two approaches.

callegar/Rezip in bash appears to be the most suitable to me. However, FreeCAD in a future version will support better integration with version control without such workarounds and additional workflow steps.

FreeCAD v0.18 and newer (or v0.19 and newer?)

Brief view of Assembly3 assembly, document, and link organization. Sub-assemblies which are linked to an external document, will result in that external document being loaded and displayed as shown. While frozen they won't consume much memory.

Has realthunder's Assembly3 workbench. Supports links, which help eliminate prior memory limitations with larger assemblies, and need for such workarounds like File_Simplification. So long as the linked document is opened and the link is frozen, the assembly is displayed within the parent document as a single unmodifiable geometry. When the linked document is closed it won't be displayed anymore in the parent document.

I think it would be best if when the Assembly3 workbench isn't active,

That a simplified view of the model is presented in the Combo view, without the Constraints, Elements, Parts and additional hierarchy that Assembly3 at present introduces to FreeCAD:

The clutter of external documents in the tree view can be hidden by the setting 'View -> TreeView actions -> Single document'. But I'm still looking for a way to hide the Constraints, Elements, Parts containers.

FreeCAD v0.20 and newer

realthunder has made changes in FreeCAD to better support Version Control, however he writes "It is still in my fork. I think this feature will most likely land in the next 0.20 release".

Save as directory for version control integration in FreeCAD v0.20 and newer and realthunder's fork

realthunder has put in the plumbing to allow an external tool/service to automatically manage the version control of the CAD files.

At this time the use of such beta features may be premature, but I imaging you'll want to migrate projects to use Assembly3 instead of Assembly2 anyway.

My envisioned solution

While the solution with the FreeCAD WebTools Workbench and rezip should work... better possibilities exist, which will:

1. Better handle multiple documents, allowing re-use of work done (why invent the wheel twice!)
   1. Each linked sub-assembly of a parent assembly will have their own document, in their own git branch, with their own history, allowing other assemblies to make use of and update that subassembly without changing the original parent assembly.
2. Transparent git integration
   1. End-user does not have to interact with git or do any additional steps, other than save and enter a commit message
3. Service will notify user of any update to a document they're working on

Use FreeCAD v0.20 once available, or realthunder's present fork.

Set up a service to respond to the signals, e.g. [1]. The signal data will include what files were modified/deleted/added. The service will:

1. Interact with git. e.g. Commit the changes to a new revision.
2. Push the new commit to a remote repository, if a remote repository is designated in the document properties.
3. Put sub-assemblies into their own branch, and use git sub-repo to include those sub-assemblies in a subdirectory in the main branch (likely master).
4. If a remote repository was designated for any sub-assembly, the service will push any change for that sub-assembly to that sub-assembly.

In addition to the service:

1. Add a means of adding properties to the document, so that the FreeCAD user can use the GUI to designate a remote version control repository to push/pull the changes to.
2. Add a means for the user to enter a commit message when they save the document.

Annotated Visual History

I'm not sure what would be the most optimal way to implement Annotated_Visual_History.

A simple idea would be to have:

1. An ".annotated_visual_history_cache" folder, which is listed in .gitignore (not versioned)
2. FreeCAD on opening a version controlled directory without, to interact with the service as the service iterates through git revisions, to cache each revision.
3. On each revision, take a set of isometric snapshots rotating around the assembly, resized to say 64x64 px.
   1. The service can possibly iterate through each revision without opening up the FreeCAD GUI.
4. An image processing utility will assign a complexity score to each snapshot, and the snapshot with the maximal complexity score will be selected as the thumbnail. A complexity score being a proxy measure of what image best illustrates the part!
   1. Filesize might suffice as an indirect measurement of complexity, the largest image being the most complex, otherwise,
   2. ImageMagick's identify might suffice, with a grep of a -verbose output, or a -features measurement, or
   3. FreeCAD 'Preferences->Document->SaveThumbnail' boolean indicates that a suitable feature may be in the FreeCAD API somewhere.
5. Have a FreeCAD workbench, such as the WebTools workbench, able to interpret the git log and these thumbnails in a meaningful way for the user

Or simpler would be to not make a cache, but just use FreeCAD's thumbnail generation as part of each versioned document. But this is binary and shouldn't be versioned if at all possible... caching is the optimal solution as illustrated earlier.

Related docs: Collaboration_Architecture, FreeCAD_101 This discussion page seemed like an ok sandbox to put my thoughts in before moving to a move formal page somewhere when I have a concrete solution.

--Andrewusu (talk) 23:22, 2 January 2021 (UTC) ]]