5 ms·

> not thinking about files And I hate app-data not being files, not being portable. My data may be stuck inside a SaaS and only accessible through a closed-sou

> not thinking about files And I hate app-data not being files, not being portable. My data may be stuck inside a SaaS and only accessible through a closed-source app, and I have nothing to say about it. > Real sandboxing, with a nice permission layer Sandboxing apps is a good thing. Depending on your use-case, Snap/Flatpak or containers kinda solve this, but they are not the default way of running apps for now. What mobile does wrong here though, is that it also sandboxes the user, not giving the user full access to his device, nor letting him let his apps get that access either. This is user-hostile, on all current major mobile-platforms. > Extremely easy sharing of data between apps I would rephrase this as barely functional sharing, for only the limited subset of data the application has decided to implement sharing for, and only in ways the application-developers have considered inter-app sharing. On a desktop, I as the user, have the power to decide how I want to share data and invent new ways data can be shared and utilized. > URIs that go deep into other apps While that is certainly a neat feature, it's an app-centric feature. How do you know which kind of apps I have installed? How do you know which of those apps within that niché I have installed? And if you're not going to make it app-centric, you have to make it file/data-centric anyway... Which leaves us Android. Android does this better than iOS by having an intent-system which lets you register ability to handle both files, urls and subsets of those, and other apps can query for which apps supports which file/url-intents. So basically just a minor addition to the system we already have had on all desktop OSes for decades now. And again: that's a system which already works really well when files are first-class concepts which everything else builds on. So it's all back to files. If you want to empower the user, you must have files.

rtpg 6y ago
Files are emphatically _not_ good first class primitives for rich sharing. If you have a contacts program, are you going to make each contact a file? What about performance or bulk editing? From that program's perspective, the ideal is probably to have a single file (SQLite DB for example). But now you don't have granular sharing mechanisms except through a clumsy export which requires you to give a name to the thing and put it somewhere and open it in the other program. Meanwhile I hit the share sheet on my phone for the Contact. Some apps know about this form for data and can ingest it. Others fallback to text. It's the clipboard model, not the files model. Files are _fine_, and it lets you do stuff like reverse engineer the format and do cool stuff. But it's clunky as hell when you have something relatively ephemeral.
- swiley 6y ago
  It turns out a group of experts has debated your example at length and come to some reasonable conclusions. https://tools.ietf.org/html/rfc6350 https://tools.ietf.org/html/rfc6350
- josteink 6y ago
  > But now you don't have granular sharing mechanisms Many (Windows) apps support OLE/COM-based objects which can be copied, mixed and processed in between applications. This allows the clipboard to hold rich objects and not just text-based contents. Things like tables, images, rich text, contacts... and even files, or folders of files! This allows for a much more rich (and empowering!) way to share data than currently done on popular mobile platforms. This was already implemented back in Windows 95 or something. It's really old tech. Not sure how well this concept is implemented (or at all) on other desktop operating systems though, so it might not be a "universal" desktop solution for everyone. That said it can clearly be done better than mobile, because on Windows it has already been so for two and half decades.

rtpg 6y ago

Files are emphatically _not_ good first class primitives for rich sharing. If you have a contacts program, are you going to make each contact a file? What about performance or bulk editing? From that program's perspective, the ideal is probably to have a single file (SQLite DB for example). But now you don't have granular sharing mechanisms except through a clumsy export which requires you to give a name to the thing and put it somewhere and open it in the other program. Meanwhile I hit the share sheet on my phone for the Contact. Some apps know about this form for data and can ingest it. Others fallback to text. It's the clipboard model, not the files model. Files are _fine_, and it lets you do stuff like reverse engineer the format and do cool stuff. But it's clunky as hell when you have something relatively ephemeral.

swiley 6y ago
It turns out a group of experts has debated your example at length and come to some reasonable conclusions. https://tools.ietf.org/html/rfc6350 https://tools.ietf.org/html/rfc6350
josteink 6y ago
> But now you don't have granular sharing mechanisms Many (Windows) apps support OLE/COM-based objects which can be copied, mixed and processed in between applications. This allows the clipboard to hold rich objects and not just text-based contents. Things like tables, images, rich text, contacts... and even files, or folders of files! This allows for a much more rich (and empowering!) way to share data than currently done on popular mobile platforms. This was already implemented back in Windows 95 or something. It's really old tech. Not sure how well this concept is implemented (or at all) on other desktop operating systems though, so it might not be a "universal" desktop solution for everyone. That said it can clearly be done better than mobile, because on Windows it has already been so for two and half decades.