While in a perfect world all application would be written where their file format is mergable. Just like the Office products where it took a years to get there.

In the real world that is just not a reality in the short term for a lot of products with proprietary file formats.

For better adoption for file handlers in onedrive I believe the following enhancements to the checkout behavior in Microsoft Graph are critical.

1. Allow checkouts to be discarded through Microsoft Graph REST. Currently check in checkout always produce a new version even if no content or metadata was changed which is very noises to end users. This functionality is available through the one drive interface why not a REST endpoint in Microsoft Graph?




2. Allow checkouts to be contextual. A lot of applications will have client/server and desktop variations. Currently a single user can successfully check a file out and/or push changes to a file from multiple contexts think multiple machines, multiple browsers, multiple tabs or multiple desktop instances or and combination of those. Current checkout does little to protect a single user from themselves. Ideally if the current checkout endpoint would accept an identifier for the session and only allow writes or check in requests from that session. Another variation would be a successful checkout would return a lock token that needs be used on subsequent writes or check ins.




3. Allow Checkouts to expire. Currently checkouts are indefinite until the same user checks the file in. Which makes sense from a simple prospective but the real world is more complicated. As we all know client/server environments are not always perfect, browsers crash, servers crash, desktop applicatios crash. it would be nice if on checkout you could give an expiration, the clients could then pulse the checkout endpoint on an interval to extend the expiration or to find out they are not the single writer and can take the appropriate actions.




4. Allow custom metadata to be attached for drive item resources. Sometimes applications needs some simple
   Key value pairs to enhance the end user experience. Allowing this to be attach to drive items could go a long way. They could even be used to mitigate some issues mentioned above

Trying to combat the concurrency issues on your own are complicated and time consuming. Building these features into Microsoft graph would lower bar for adoption.

The OneDrive service on IFTTT is great, and it allows users to use OneDrive with hundreds of other services. However, one BIG limitation is that OneDrive provides no way for the user to make sure the file has a unique name (and therefore doesn't overwrite a file that has potentially been created the same way previously). All this would take would be a UNIX timestamp ingredient for the IFTTT service. Many other services does this, and it would open the door for so many more things to use OneDrive with/for on IFTTT.

I for example use OneDrive as one of the cloud service options for a piece of software I made, that 30.000 users use - thousands of these users experience problems with OneDrive every day due to this, which sadly results in me having to suggest they use Dropbox who is apparently better at handling it when a file is being overwritten on your computer. With OneDrive the error; "The cloud synchronization provider could not validate the downloaded data." often appears due to this. If the files could have a unique name, it would completely eliminate this error (that is OneDrive having issues with properly downloading a file if the file is being accessed on the PC before it's fully synced, then it refuses to finish the download and the file has to be deleted manually)