Thanks! The project consists basically out of two components, the runtime and the editor.
The runtime is mostly self-written, focusing most of my efforts. The editor on the other hand is built on `rete.js` (https://retejs.org/) and Angular. ReteJS is a really amazing node editor framework. While I customized almost everything that was possible, a lot of credit goes to them.
In hindsight, Angular might have been a little bit of overkill, but it's the framework I'm comfortable with, given my very limited web development experience.
I have always been a fan of GitHub Actions workflows but for some reason never liked YAML files as being the assigned file format for non-linear workflows. While YAMLs are great as configuration files, they can be quite tedious when it comes to creating, reviewing, and maintaining workflows.
To solve this, I created a visual node system that makes the workflow creation and maintenance process more efficient and intuitive. It's a straightforward node engine with an UI editor.
There is a lot going on in the space right now and there will be certainly a big shift in the next years. But as long as Blender, Cinema 4D, Photoshop, Pixelmator, Affinity are not running in the cloud I rather feel like DCC software packages and tablets will introduce a change first
I should clarify this. The 100 MB window in SnowFS is currently unrelated to compression as it is only used to compare if a block changed. Each block gets a hash. This is a fallback used for some file formats where the mtime timestamp cannot be trusted. Some files have a change in the first block e.g. 100 MB and that is faster to compare than an entire 8GB file. But this window size is dynamic and can be changed and used for compression in the future
Ahh this is my bad. For some reason I assumed the blocks were part of the storage scheme, but I see they only are used to compute hash, and that the whole file is added to zip. Sorry for the misunderstanding!
I am currently working on the compression, as it is not complete yet. The 100 MB is indeed excessive but the window is dynamic and can differ from file to file since it is written to a `*.hblock` file which is stored next to the object in the object database https://github.com/Snowtrack/SnowFS/blob/03e5f839326e666c891...
Let me explain where the 100 MB window comes from as its not only related to the upcoming compression implementation. Some graphic applications touch the timestamps of their files for no reason, making it harder to detect if a file changed. But some file formats always change their 'header' or 'footer'. Means, comparing the hash of the first or last 100 MB of a file that is 8GB in size gives a great performance boost to detect if a file got modified.
Unfortunately, Snowtrack has no collaboration workflow yet. The underlying file storage system is prepared to support collaboration in the future, but it's too early for this
The runtime is mostly self-written, focusing most of my efforts. The editor on the other hand is built on `rete.js` (https://retejs.org/) and Angular. ReteJS is a really amazing node editor framework. While I customized almost everything that was possible, a lot of credit goes to them.
In hindsight, Angular might have been a little bit of overkill, but it's the framework I'm comfortable with, given my very limited web development experience.
The editor is available here on GitHub and should work out of the box with the default VS Debug Configuration https://github.com/actionforge/graph-editor