Tricky thing here is, where do we store these lenses? Different applications will have different needs, and thus different lenses. What if we stored the lenses, or json patches, along side the data?
That way apps can revert the data back to the common schema, or perhaps a common lens (I think the cambria lens graphs make this possible). Apply their lenses, and then store the data and the lenses they used.
This is a recurring topic in remoteStorage as well:
My way of doing it would be:
assume that the notion of schema is not static or cannot be ācommonā, that there will always be inconsistencies (between multiple apps, between different versions of the same app, between representational differences like JSON vs RDF)
that those inconsistencies extend to ācommon pathsā too
apps can declare lenses for translating their custom format and custom paths to a more common ones (there does not need to be consensus on which ācommon onesā), perhaps as part of manifest.json
use something like Cambria to re-interpret paths and formats at runtime
Schema compatibility: do all the editors need to agree on a single rigidly specified format? If there are reconcilable differences between formats, can we build ālive convertersā that convert between them on every change? (Essentially, imagine collaborating between Pages and Microsoft Word, running a file export in both directions on every keystroke from either app) This problem is closely related to the problem of schema versioning within a single editor, but BYOC can complicate things much further.
Preserving intent: the decoupling of git + text editors has a downside: the text format fails to capture the intent of edits, so git canāt be very smart about merging conflicts. Is this something fundamental to decoupling editors from collaboration? Or are there ways to design APIs that preserve intent better, while also supporting an open client ecosystem? (It seems like deciding on how you store your data in a CRDT is the key question here?)
Additional editor-specific metadata: Some editors need to store additional data that isnāt part of the ācore data model.ā Eg, Sublime Text stores my .sublime-workspace file alongside the code source. How does this work smoothly without polluting the data being used by other editors?
Code distribution: Traditionally code distribution happens through centralized means, but could code be distributed in a decentralized way alongside documents? If weāre collaborating together in a doc, can I directly share a little editor widget/tool that Iām using, without needing to send you a Github link? This might be overcomplicating things / orthogonal to the general idea hereā¦ (This idea inspired by Webstrates, linked below)
Innovation: Unfortunately stable open formats can limit product innovationāeg, email clients are tied down by adherence to the email standard. Can we mitigate that effect? I think web browsers have struck a good balance between progress and openness, despite frustrations in both directions.
Would a āscripting appā be useful? That is, a Fission app that loads in a userās filesystem, the user writes a script to perform, then the result is saved to the filesystem. Could be useful for data processing?
Users should be able to customise where an app looks for data (effectively changing its permissions). This could be done by saving a āpermissions config fileā in the app data folder.
Yes! I want this. Iād love an app that takes some sort of declarative dependency declaration file and makes sure everything in the filesystem is āup to dateā. Something like makefiles/justfiles/shake etc.
Thereās also some interesting research done by shake about these things: https://dl.acm.org/doi/pdf/10.1145/3236774
i think all of the unresolved questions are part of what cambria claims to do automatically: determining which lenses to apply when so that the consumer doesnāt have to. if i remember correctly, in their model you store a āschema version numberā with the data and pass it to cambria to help determine which lenses to apply.
Noel De Martin from the SOLID community recently wrote some ideas about apps interoperating spontaneously, framing in terms of Cory Doctorowās three classifications, describing shortcomings of centralized vocabularies and Cambria lenses, thereās a nice thread with some thoughts from @boris, be welcome to jump in
