Today FSA's are used only for transferring data from Main Server to a user. The other way round works inefficient.
- Adding a member or Check-In of a member from an FSA's Location will transfer the member first to the Main Server, and then -if the user have default client settings- directly back to the FSA's BULK. This causes double traffic.
- Doing an upload will be done automatically with content and creation of Meta Data. There won't be checked in any kind whether there is maybe a high workload of other activities like synchronize, configure, checkpoint, etc.
Main intention of above described behaviour will be to garantuee a confident data storage which is already important.
Especially the resulting traffic like described before makes the upload not as optimal like it should be.
My improvement idea is the following (compare with data tresor concept of SAP PDM):
- The storage of data on an FSA needs to be as secure as on the Main server. This is the pre-requisite for next parts of improvement.
- The upload should first create new meta data on the main server, combined with the info on which Proxy the new revision has been stored until the content have been transported physically.
- Physical upload of content should only be done if no other activities are running on the FSA.
- If a user from any location tries to sync the new data which are stored on the Proxy intermediately, the Main server will order the delivery from the Proxy to him to also forward it to the requestor. This should be done as part of the transfer to the Main Server (without first create the DB BLOB entry).
- Comparable to the autofetch in background now the content should be uploaded latest to the main server.
