Working offline with local workspace and cache

robert_zschoche

OK. Thanks for the input everyone.  I don't think there is much more to said on this topic.

pete_yodis

robert_zschoche said:

OK. Thanks for the input everyone.  I don't think there is much more to said on this topic.

@robert_zschoche All the best in your endeavors

jon_stern

I haven't read all the way through this old thread, but it looks like no one who has commented so far spends much time in China, where internet connections and VPN access can be very unreliable.

We frequently have engineers visiting our China-based suppliers, and either in connection with those visit, or because of something that's come up back in the US, they have to do some CAD work.

I've been playing with OnShape for personal purposes, but there's no way a company like mine could use it without there being offline support.

tyeth_gundry

Its almost done with summer 2022, and most of the onshape world still suffers when transitioning between 3/4/5G or brief outages on public wifi. I'm in a lovely spot between two cell towers and it changes every 30seconds.

 Can we just add the option to continue working at your own risk? Id pay a single license for short-term offline support, like buffered save at users own risk (don't close browser), and if you want to do it properly then any merge conflicts forces you to save a new document.

urs_egger099

I think Onshape is not primarily about CAD but more about the consequent single source of truth approach. That is unique and a real big deal. The data is where it is edited without any copies to sync or check in. It stays there and is visible in real-time for other users. Everyone who knows complex assembly structures with geometry links to other parts and its version management understands that onshape does an outstanding job in data management. No other file-based cloud system can ever do that in the same manner.

So onshape please never ever kill the single source of truth approach. It is why we love onshape!

michael_zeagler

One of my peers has spent some time in "van life" and toured the states and Central/South America while syncing with PDM over VPN to her worksite in Canada. I agree this is an edge case, but wouldn't it be technically feasible to branch a specialized workspace, run it inside Docker on a local machine, and periodically merge?

I see what people say about "single source of truth," but with a Git type workflow it's not strictly necessary. PDM/SVN is a pain with version control and simultaneous edits, but the Git type branch/merge is actually great at this. Onshape has implemented it in a way that you don't have to be an uber nerd to make it work, too. And it'd enable at least some edge cases. If people want "ownership" and think they can do a better job at security than AWS they're probably fooling themselves, but just wanting to work where you want is a little different.

S1mon

In theory, something like what you're suggesting would be possible, but then there becomes not only the issue of keeping the CAD files in sync when you do connect to the cloud, you would also have to keep updating the software that runs behind the scenes. The backend doesn't just change every 3 weeks, there are small updates and bug fixes which happen (mostly) silently more often. There are a number of different server processes which all need to talk to each other. To have the full power of Onshape, you'd need not just a snapshot of what's current your CAD database, but the whole history. I really don't know what this footprint looks like as they hide that pain from us as users, but having managed PDM Pro servers for Solidworks, I have to think that setting up a home machine which would handle all of that would be much more complex than grabbing a random laptop/tablet/phone and a current-ish browser.

michael_zeagler

I was thinking it'd all run on one machine with a container per server process. I don't know what the system requirements are for server-side stuff but I assume it's hardware agnostic running on containers there too. If it's really resource intensive I'd bet that'd be a bit of a wet blanket.

The size of the snapshot is an interesting problem though. I wonder if there's a way to get away with just the most recent changelog.