Reminds me a bit of newtonOS's SOUPs, and also OpenDoc. One of the challenges is that of "standards", and i shall point to XKCD -- https://xkcd.com/927/ -- There will always be something in each of these "data domains", calender/time, photos, docs, where someone/something wants a slightly different set of data/meta-data then those offered by the "generic" data formats... I dig what you are saying, but it is _all_ in the data and formats, and you are unlikely to get universal agreement as to what those should store... (or how they should display, etc etc). Very challenging, but would be awesome!
Well that's also true of HTML, but you couldn't call that an unsuccessful format! Or email/MIME. I think an open market creating a long tail of data properties from the most commonly used down to snowflake or personal "standards" is completely fine.
Sure, but then the "app" is the thing that draws/interacts/offers-the-ui for the data, and if ppl want specific meta-data, then we still have "apps" for those specific data/meta-data, no? Maybe the data is more "public", in that it is not walled off, but _somebody_ has to write interop for those specific data/meta-data extensions...
Well if you're down the long tail then you're either working with raw data and the property names are like columns in a spreadsheet, or ...
.. or, one of the recognised standard types back up in the short end of the tail is similar to HTML in that you can build your own custom UIs with it, that do understand that snowflake type of yours. This brings us into "how do you program in OnexOS?", which is the subject of an article about three articles away from now! But it's still quite like spreadsheets.
But it's still not an app - before you throw that objection in! You can re-use your out-in-the-open data by simply linking to it from another "app". And the UI can be re-used as well in another "app" to let you interact with that data type in any other context. The idea is to break data types down into little bits with little UIs to render and interact with them, so apps can be composed and mashed up easily by normal folk.
If your type and app become popular, then of course, it's a candidate for the short end of the tail - it can be merged in as a recognised "standard" type.
Which brings us back to OpenDoc and Microsoft's OLE. I look forward to reading more about this idea, and of what the differences are which will help to avoid the dead-ends that those two technologies ended up in.
OK, I've done my homework and yes, I can see the strong parallels with OpenDoc that you are spotting. To be honest it does feel a bit uncanny reading about it!
Without digging deeper, superficially it seems the main difference is in the extreme open data and data driven orientation (and declarativity) of the Object Network, versus the still app-like, data owning and imperatively programmed applets of OpenDoc?
Could an OpenDoc doc link to a chunk of typed applet data on another server? Would that data be human readable, and editable directly by its owner? And could the user not just build complex docs from parts, but program the interactions and behaviours of those parts themselves?
I also want this with small notes from manufacturers letting me know details of the consumables that need replacing; eg what kind of light bulb does the fridge need?
Exactly, and I said exactly that myself (in something somewhere recently that I can't find!)
So you'd zoom up to the light and be able not just to grab its link for use elsewhere, but to set its brightness and other config, and, yes have some maintenance info, maybe including an Amazon link. And why not be able to paste in your own notes and links?
Maybe when the light detects a fault, it can even put the part it knows it needs into your Amazon basket, with a simple rule you can write yourself!
Think I'm right? Think this is bonkers? Do you wish you'd have thought of it first? Think I should get off the internet? Want to expand on the ideas here? Then go ahead and comment!!
Reminds me a bit of newtonOS's SOUPs, and also OpenDoc. One of the challenges is that of "standards", and i shall point to XKCD -- https://xkcd.com/927/ -- There will always be something in each of these "data domains", calender/time, photos, docs, where someone/something wants a slightly different set of data/meta-data then those offered by the "generic" data formats... I dig what you are saying, but it is _all_ in the data and formats, and you are unlikely to get universal agreement as to what those should store... (or how they should display, etc etc). Very challenging, but would be awesome!
Well that's also true of HTML, but you couldn't call that an unsuccessful format! Or email/MIME. I think an open market creating a long tail of data properties from the most commonly used down to snowflake or personal "standards" is completely fine.
Sure, but then the "app" is the thing that draws/interacts/offers-the-ui for the data, and if ppl want specific meta-data, then we still have "apps" for those specific data/meta-data, no? Maybe the data is more "public", in that it is not walled off, but _somebody_ has to write interop for those specific data/meta-data extensions...
Well if you're down the long tail then you're either working with raw data and the property names are like columns in a spreadsheet, or ...
.. or, one of the recognised standard types back up in the short end of the tail is similar to HTML in that you can build your own custom UIs with it, that do understand that snowflake type of yours. This brings us into "how do you program in OnexOS?", which is the subject of an article about three articles away from now! But it's still quite like spreadsheets.
But it's still not an app - before you throw that objection in! You can re-use your out-in-the-open data by simply linking to it from another "app". And the UI can be re-used as well in another "app" to let you interact with that data type in any other context. The idea is to break data types down into little bits with little UIs to render and interact with them, so apps can be composed and mashed up easily by normal folk.
If your type and app become popular, then of course, it's a candidate for the short end of the tail - it can be merged in as a recognised "standard" type.
Which brings us back to OpenDoc and Microsoft's OLE. I look forward to reading more about this idea, and of what the differences are which will help to avoid the dead-ends that those two technologies ended up in.
OK, I've done my homework and yes, I can see the strong parallels with OpenDoc that you are spotting. To be honest it does feel a bit uncanny reading about it!
Without digging deeper, superficially it seems the main difference is in the extreme open data and data driven orientation (and declarativity) of the Object Network, versus the still app-like, data owning and imperatively programmed applets of OpenDoc?
Could an OpenDoc doc link to a chunk of typed applet data on another server? Would that data be human readable, and editable directly by its owner? And could the user not just build complex docs from parts, but program the interactions and behaviours of those parts themselves?
I'll have to go look at Wikipedia for a few mins... Meanwhile, thanks so much for your feedback, much appreciated!
I also want this with small notes from manufacturers letting me know details of the consumables that need replacing; eg what kind of light bulb does the fridge need?
Exactly, and I said exactly that myself (in something somewhere recently that I can't find!)
So you'd zoom up to the light and be able not just to grab its link for use elsewhere, but to set its brightness and other config, and, yes have some maintenance info, maybe including an Amazon link. And why not be able to paste in your own notes and links?
Maybe when the light detects a fault, it can even put the part it knows it needs into your Amazon basket, with a simple rule you can write yourself!
Think I'm right? Think this is bonkers? Do you wish you'd have thought of it first? Think I should get off the internet? Want to expand on the ideas here? Then go ahead and comment!!