These goals are relative to the prior client.
E.g., use SqLite, and don't depend in the basic library on iOS UI features such as UIKit. This will also mean splitting off the sign-in components to their own library. Windows may be a target too-- Swift is about to be available there. Web UI is also a possiblity, but that seems out of the Swift realm.
This is so that I can have a Sharing Extension, where in the Apple Photos app, you can get an app like Neebla to upload a file. Currently the architecture of the iOS client and Neebla won't allow for this. Use a shared container? Can a library enforce this?
https://github.com/crspybits/SyncServer-Shared/blob/dev/Sources/SyncServerShared/RequestsAndResponses/FileInfo.swift Also look at the collection of versions. I think there is more than just a file version.
E.g., a video file type, and a HEIC file type. And live photos.
That is, currently the library takes control over when and how how many files are downloaded from the server. Instead, I want the client app to take charge of this triggering-- e.g., so the client can decide what to do in the foreground and what to do in the background. I think the same situation applies for uploads. E.g., if there are 10 files needing upload, the client will trigger the "when" of those uploads. In terms of downloading-- the client should also have control over what types of files get downloaded first.
E.g., if there are icon images, the client should be able to prioritize those. Also, the client should be able to have attribute information on other files for figuring out how to prioritize their download.
Currently the client framework forces a client to always download all files from the server. This isn't tractable. It takes a long time. It may take more space locally than a user has. It isn't compatible with having the app downloda all icons first, and then large images at a later (say, on demand) time.
Generally, I want it to be easier for an app to be written to use this library. Right now, it's pretty complicated.
One of these issues are dealing with different ordering of file downloads. Sharing groups can have multiple files. And those files can be downloaded in different orders. And this means an application has to deal with integrating those files into its own data in various ways depending on those download orderings. Could we unify the download of sharing groups with different sets of files? OR-- Perhaps that'll be dealt with by providing the application with control over downloading-- which we are planning to do!!
Even if we have to take some strong opinions about conflict resolution.
If there is a collision, it will occur on the server. We need to be able to inform the client so it can update its records.
I'm going to get rid of "master versions". The purpose behind this was to ensure that a client has the same snapshot of data downloaded whey they were uploading their data. This is very constraining, however. And it introduces possible race conditions, when particular files have a lot of server traffic-- from other clients.
I'm going to keep file versions, but in a more limited manner. Clients will not be required to supply a file version when uploading. Nor when downloading. They will simply act on the current state of the data. Versioning will be used when downloading, however-- so that one version of a file can be downloading while the next version is being updated.
I'm also going to remove appMetaData versioning. This seems excessive. Instead, I'm not going to allow changes to the appMetaData beyond that uploaded with v0 of a file. While there are currently methods that allow for appMetaData versioning, they are not being used by Neebla-- the only app using this system.
I'd like to have this more general. E.g., to be able to make one file completely public.
Use SwiftUI. And not just the code itself-- the UX/UI form and appearance of the controls need work for usability.
Right now it's too complicated, hard to test, and hard to maintain. Part of this is that there are numerous singletons being used. Part of this has to do with having the completion of one server operation cause the initiation of another-- or rather the next server operation (upload or download). This forms a complicated state machine where download states transition to upload states, transition to a commit-uploads state. Combined with failure states which require forms of rollback.
Part of this restructuring needs to take into account that, for upload at least, we'll be triggering multiple possible uploads (i.e., for a file group) effectively simultaneously. We have to make sure that the server can handle these concurrent uploads from a single client. And, once the group of uploads is completed, that a commit-uploads operation can be triggered-- and that the commit-uploads is triggered only at that point.
It's too hard to figure out right now if a needed test is present in the set of tests. Testing needs restructuring and simplification.
From other apps (e.g., Apple's photo app), upload a file or file(s).
Instead of showing the images first, the discussions are displayed. And you can navigate to the related images.