3 ms·

The handwriting recognition was the Newton's oversold aspect, leading to (in my opinion) many to overlook some unique system-wide architecture decisions for dat

The handwriting recognition was the Newton's oversold aspect, leading to (in my opinion) many to overlook some unique system-wide architecture decisions for data representation; the data soup [1]. That technical description doesn't easily convey the benefits for those who have never seen data soups before, but this blog post [2] gives some idea. [1] https://en.wikipedia.org/wiki/Soup_%28Apple%29 https://en.wikipedia.org/wiki/Soup_%28Apple%29 [2] https://blog.mozilla.org/faaborg/2007/06/29/why-the-iphone-is-no-newton/ https://blog.mozilla.org/faaborg/2007/06/29/why-the-iphone-i...

jegoodwin3 11y ago
This was very helpful. Thanks. The second link made it sound very smalltalkish to me -- it sounded like an OODBMS that real world users could relate to. So I followed the link at the Wikipedia article and was surprised to learn that NewtonScript was a prototype-based inheritance language modelled on Self. If the secret sauce is a user-accessible OODBMS written in a prototype-based scripting language, would it not be possible to build a Data Soup system in JavaScript? No need to bring the device back -- just replicate what people liked about it.
- yourapostasy 11y ago
  You totally can re-implement the data soup in JavaScript. At the same time, revamp the data soup for a default-untrusted environment (with accompanying management UI/CLI/API), and extend it to multi-user contexts, and I think it's worthwhile to explore for use in groupware. I'm not entirely convinced the way we're currently sharing referential data in groupware is sustainable, though I don't know large-scale data structure design well enough to know if a new kind of data soups approach would be any better for a global scale. My gut reaction is data soups are not extensible to the global Net, but groupware-oriented applications would likely benefit since there is so much back- and cross-referencing in groupware transactions. The data soup's union capability would be ideal for helping manage mobile "islands" of data, as consumer/employee mobile devices add ever-greater capacity and synchronization to the data on those devices is introducing unacceptable latencies to live, accurate data representation.

jegoodwin3 11y ago

This was very helpful. Thanks. The second link made it sound very smalltalkish to me -- it sounded like an OODBMS that real world users could relate to. So I followed the link at the Wikipedia article and was surprised to learn that NewtonScript was a prototype-based inheritance language modelled on Self. If the secret sauce is a user-accessible OODBMS written in a prototype-based scripting language, would it not be possible to build a Data Soup system in JavaScript? No need to bring the device back -- just replicate what people liked about it.

yourapostasy 11y ago
You totally can re-implement the data soup in JavaScript. At the same time, revamp the data soup for a default-untrusted environment (with accompanying management UI/CLI/API), and extend it to multi-user contexts, and I think it's worthwhile to explore for use in groupware. I'm not entirely convinced the way we're currently sharing referential data in groupware is sustainable, though I don't know large-scale data structure design well enough to know if a new kind of data soups approach would be any better for a global scale. My gut reaction is data soups are not extensible to the global Net, but groupware-oriented applications would likely benefit since there is so much back- and cross-referencing in groupware transactions. The data soup's union capability would be ideal for helping manage mobile "islands" of data, as consumer/employee mobile devices add ever-greater capacity and synchronization to the data on those devices is introducing unacceptable latencies to live, accurate data representation.