This is a half-formed thought, so I'm just putting it here to track any discussion.
The original version of Ocelot only operated on local files, but there lots of situations where this is a nuisance. As of 3.0 we already have a couple methods for accessing remote data:
Fetch projects from Lingotek
Save files to Azure
It is easy to imagine there will be a lot more of these, since they're very useful for CMS/TMS integrations. However, the File menu (and possibly the code base) will soon become overrun by these things.
So there are several components to what I'm suggesting:
Reorganize the File menu to use "Open From..." and "Save To.." submenus to keep the UI manageable.
Look into improving the internal abstraction for "Open from" and "Save to" implementations to help keep the code more organized. This will also make it easier to centralize the configuration of these types of plugins in a config UI or a common format in .ocelot.
Optionally, allow these type of implementations to be installed as plugins, so that we can implement customer-specific integrations that don't make sense outside of one particular environment.
These 3 things can be implemented separately, but they all build on each other. Regarding #2 and #3, based on what's been done already it seems pretty clear that we need to treat "Open from" and "save to" as two separate (but related) use cases. In other words, it should be possible to implement writing data out to a particular store but not reading to it.