Open ArkadiYoskovitz opened 6 years ago
This library and UIDocument have totally different approach on files. UIDocument is about tracking changes, versioning and resolving conflicts. Whereas this library considers documents simply as a file.
You can use this library inside an UIDocument for enlisting, reading, writing and reporing progress. But you must implement an additional layer for version tracking and resolving conflicts.
True but, should not there be a way to use this library for directory observation and only change the way in witch you write/read the file to mediate the differences?
The file search, attributes fetch, directory monitoring & lookup, item copy, item move, item remove and such still work the same way.
It's only the initial file creation that's different
The file search, attributes fetch, directory monitoring & lookup, item copy, item move, item remove and such still work the same way.
These operations are stateless. We just query the server and tell it what to do.
Observing changes and versioning are entirely different thing. They need a database to compare and keep files and directories status. Furthermore Dropbox, OneDrive, GoogleDrive and iCloud keep revisions while local, WebDAV and FTP has no internal system to keep older version of a file.
I have no idea how to handle this. If you have a concrete plan, PR is welcomed.
This looks like a great pod but, is there a way to work with UIDocument subclasses?
Say i want to build a custom document class to host my apps' model information and i want to use this pod is there any way yo write out the document to disc? i only found methods that write Data objects and there didn't seam to be any way to extend its functionality, any comments on the subject will be welcome