3 ms·
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 abou
by 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 agoIt 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.