See Google Doc for New WIP Structure

https://docs.google.com/document/d/12du6jhgV2ifR7IV8nfTaC20sdfsx8A39oGmF1N-Diu0/edit?usp=sharing The below text is mostly all outdated, but I'm keeping it here because there is some info that I want to keep that isn't in the above link yet.

Abstractions

These are the interfaces that we interact with that we have no control over

Cloud Storage Provider

These include the service that actually stores the data in the cloud, such as OneDrive, Google Drive, Drop Box, et. al. These services are not required to provide any kind of format, but the implementers of IConnection for each service must provide a given set of functions.

Local File System

This is abstracted through the .NET core for uniform access to the local file system of the client system. The application must have write access to each folder configured for syncing. The file system must also support events for when items change in the file system.

Interfaces

These are independent components that can theoretically be swapped out with other implementations if desired.

IConnectionFactory

Each Cloud Storage Provider will have a plugin that has a class that will create a new instance of the IConnection for that particular provider. This factory will contain additional information, such as token caches, necessary for using the service as a whole on the client application.

IProviderPlugin

Each Cloud Storage Provider will have an implementer of this interface that will add any kind of extension to the function of the application. How exactly this will function is still to be determined.

IConnection

Each Cloud Storage Provider must have a class that can interact with it. This class must implement the IConnection interface, which requires the following features:

Silent authentication

When the application starts and the token has not expired for the service, the connection will authenticate without prompting the user

Upload/Download/Rename/Copy/Move/Update

Modifying the file structure and file contents are obviously necessary for having local changes sync to the remote, and remote files must have a method of downloading them.

Item Deltas

When files change in the remote, there must be some way to communicate that back to the application, be this WebHooks or just a request that must be made periodically to the IConnection.

IConnectionEncryptor

This class will appear just like a regular IConnection to the user, but it will apply some sort of encryption to the data and potentially the names of the files. The application must be completely unaware this is happening.

IItemHandle

This very important interface provides the owner read access to a resource (local or remote), but it is a non-static resource. This means that there may be changes in either the local or remote state that invalidate the handle or change its properties in some way. For example, if a file got deleted or renamed, the handle would be pointing to a file that no longer exists. If the content changed, however, the handle will not be invalid. There may or may not be a validate method for the handle, but the preferred solution is to try to access the resource and catch any exceptions that may be caused by it being invalid.

RemoteDeltaConverter

This component will take ItemDetas dispatched by the RequestDispatcherand convert them into a format that fits the IConnection interface. Since it interacts with the IConnection interface, it must handle any error cases and report them back to the RequestDispatcher in an easily displayable way. This information will be reported to the user along with any necessary prompt

RemoteManagement

Not all communication can be done over webhooks, so this layer is to periodically pull the deltas from the provider and apply them to the metadata. The actual changes won't be applied until the metadata sends the event to the local and the local requests the stream.

Item Delta Filters

A container of filters that will either let a delta through to its destination or not. Any number of filters can be added to either the local set of filters or the remote set of filters. This is to let the user decide which files they want to sync. These do not have to be the same for the local and remote, but they typically are.

Request Switch

A single IConnection can be connected to n local folder locations, so this switch will delegate events to their appropriate locations based on the path of the request. This also assists in the process of online access to blacklisted files.

Event Converter

As a counterpart to the RequestSwitch, this will take events from each of the local file store locations and rebuild the path of the associated item. The event then gets sent up to the filters.

Cached FS Location

This wrapper around the Local FS location changes the file names and flattens the directory structure for cached files so they can be easily accessed. This location is specially delegated to when a request is made to cache a file from the API. It can be signaled to clear all of its contents manually, or automatically based on some fixed duration, size limit, or both. Events from this location are converted to relatively normal file system events, so to the Event Converter, they will appear as if they came from the real location on the disk

Item Metadata (WIP)

This database will store data for each item in the store. The data stored for each item is extendable, so the basic features of the ItemMetadata will not be compromised by adding more data to it in the future. Each item will contain basic information, including a unique identifier, current local path, last known remote path, an identifier for the CloudStorageProvider, last modified date/time, whether it is a file or a folder, its parent's id, among other things. Files will have an SHA1 checksum. Lookup to this database will be via strings to emphasize extendibility, but it is encouraged to have global constants with these string values. Access to this metadata will use cooperative-blocking for maximum performance and safety. Changes to the metadata will trigger events, which is what will cause a local change to push to the remote. Rebound events will be filtered out by the nature of the structure. If there is no change to the data, as is the nature of a rebounded delta, then no event will be sent. Changes to the metadata must be accompanied by an IItemHandle to that item, whether local or remote and can be distinguished as a local or remote update based on the type of item handle that is passed.

Data

Among any number of other things, each item will include

• Name of the item
• Unique identifier for the remote object
• Last modified of the "row"
• SHA1 checksum (blank for folders)
• Last modified of the local version
• Last modified of the remote version
• Size of the item (gets updated upon local event)
• Conflict State (i.e. "good," "conflict," or "close application (being blocked)")
• If it is a folder or a file