Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request - update the SyncFileService to use a file system provider #571

Open
NikRimington opened this issue Dec 13, 2023 · 0 comments

Comments

@NikRimington
Copy link
Contributor

Is your feature request related to a problem? Please describe.
We are trying to create a reusability/baseline style suite of RCL's that include uSync definition files so that they can be installed into a site and imported to give a starting point. However the idea is things are "modular" so what you have depends on which RCL's you install and their dependencies. The problem is uSync doesn't read the definition files from the RCL's.

Describe the solution you'd like
There are two possible ideas that could work as solutions:

Having investigated how the uSync source code works, it would great it the SyncFileService was updated to use the file system provider instead of interacting with System.IO directly. System IO, as I understand it, accesses the file system directly, where as if it were to use a files system provider it would pickup the RCL locations. Additionally if the SyncFileService had the file system "provider" injected in then different file systems (blob storage for example) could be used to store the uSync files.

The second idea (that is not fully formed at this time as only manifested while writing the above) is that if the current SyncFileService was made abstract or it's methods overrideable and had an interface on it, then it could easily be overridden/partially overridden so someone could create a custom version for only parts of the service - in the example above the only methods that need to be overriden would be GetFiles and possible OpenRead as they would need to consider both System.IO and a custom provider - writing would then fall back to System.IO as normal.

Describe alternatives you've considered
Considered using item templates but can't have dependencies on other templates (i.e. installing 1 template installs additional ones automatically), considered content by code - but this is too much of a break from standard Umbraco behaviour, have also considered custom migrations that write the file to disk during start up but there is a risk of incorrect overrides.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant