kevinmackenzie / localcloudstorage Goto Github PK

This class will have a minimal interface, but has a background loop that is where the work happens. It periodically polls a provider for updates and then sends them to the item metadata.

Handles startup and construction of the aggregation layer and the instances. It will also handle application-level control (handling system events and presumably other things).

Sometimes the user wants to reconfigure the file system switching structure. This cannot be done while the instance is running, but the user should have the option to make this change. Migration is how this will be done. See doc for more details.

The first provider supported will be OneDrive since that is already what I have experience with on the previous revision of this project.

The file system will send events when local file system items change. These must be parsed and translated into item deltas to be sent up to the ItemMetadata

As the hub of all events and things that happen in an Instance, this should have a rock-solid set of interfaces with robust internals. It should be fully thread-safe.

Many of the events that occur will need to wait for some long-lasting event (network access/filesystem access). It is important to have a component that will allow these ItemDeltas to propagate to its destination without locking up the caller until then. This will probably act like an asynchronous queue.

This class will construct a cloud storage instance from the components described in other issues (#1, #2, #3, #4, #5). It will generate a public viewmodel class that contains a ready-to-run instance. (#7)

We can't guarantee this application will be open all the time, so it is important to be able to scan through the local directory structure upon startup / on request to see if there are any updates to push to the remote.

This layer composes all of the Instances and views together and links them together.

This class is the interface between the instance and the aggregation layer. It allows read access to all information about deltas and item metadata along with other useful information, such as connection stats. It also is the only way to receive and resolve item delta conflicts.

There are two primary classes to accomplish this. The first is an abstraction layer on top of the file system to apply and generate ItemDeltas. The second is a class that will demux item deltas to the particular local file system locations that they should be going to (based on item path).

An asynchronous logging class for each of the instances. Can filter by severity, origin, component, time, etc.

We don't want to saturate the user's connection, so there should be a layer that monitors the total network usage and limits upload speeds across all instances to be sure it doesn't exceed cap.