From Newsgroup: alt.folklore.computers

I remember back in the 1990s, there was this great push to promote a rCLdocument-centricrCY approach to architecting desktop applications, as opposed to the traditional rCLapplication-centricrCY way.

In the traditional way, each document was managed by a single
controlling application. Thus, you had word-processing documents
managed by a word-processing app, spreadsheet documents managed by a spreadsheet app, etc. To create a new document of the right type, you
had to launch the right app.

In the new way, a document could be a composite of rCLpartsrCY, which
could have different types of structured content. E.g. you could have
a word-processing part and a spreadsheet part within the same
document. Clicking inside the word-processing part would activate,
behind the scenes, the relevant set of code that would previously have
been a separate word-processing app, but which now lived within a
single common process context associated with that document. Click
inside the spreadsheet part, and that activates the spreadsheet code.

The key point about all this being that the code handlers for those
different rCLpartsrCY could be created by entirely different software
vendors, and sold separately. So you didnrCOt have to buy a single
all-singing, all-dancing application suite from a single vendor, you
would (in theory) be able to pick and choose from various competing alternatives on a much more granular basis.

Did all this turn out to be too complex for users to manage? Or was it
merely killed by the usual war-of-competing-proprietary-standards,
with Microsoft in one corner with its OLE 2.0 architecture, and Apple
in the other with OpenDoc?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Sun, 10 May 2026 22:53:44 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

Did all this turn out to be too complex for users to manage? Or was it
merely killed by the usual war-of-competing-proprietary-standards,
with Microsoft in one corner with its OLE 2.0 architecture, and Apple
in the other with OpenDoc?

It's been a minute and I never dug into the nitty-gritty, but AFAICT it
was a bit of both. I don't doubt vendors' instincts for lock-in played
a part, but I think it was as much (if not more) that creating a robust
& extensible framework for tying together multiple disparate-but-inter- operable components is Hard, Actually.
It's easy to *say* "the spreadsheet part," but in order to implement
that in a real-world context you have to define what a spreadsheet is,
and that entails defining all the things it *isn't.* Say you discover
later that there's a need for [spreadsheet] to include XYZ frobnitzen
that weren't part of the initial spec (or, with commercial interests
involved, that Marketing *decides* there's a need.) Now the conceptual
scope of [spreadsheet] is larger than the [spreadsheet] standard...
Do you let vendors go ahead and implement it in their own [spreadsheet] components however they will? Then you lose interoperability, since XYZ
will be limited to the internal scope of a [spreadsheet] and get lost
if you try to bring it across into something else (the old "rich text
doesn't copy/paste correctly" problem.)
Do you let vendor X take the lead, and everyone else copies their work?
Then XYZ is liable to pick up their idiosyncracies, and may not mesh
well with other vendors' way of doing things.
Do you try to wrangle a standards body into defining the XYZ extension?
Then you push back the implementation of XYZ months or years, all while
the *need* for XYZ goes unfulfilled in the meantime - *or* you move
ahead with one of the first two options and try to reconcile standard & implementation after the fact, which inevitably turns into a clownshow.
And the mechanics of implementing "very many arbitrary interoperable components" as a design strategy are their *own* challenge, especially
if they're sharing a process space or otherwise have the means to make
Stuff happen automagically. Just look at how many security issues OLE,
ActiveX, and VBScript have been responsible for, and that's largely
within the range of *one vendor's* products.
It's a lovely *idea,* but I'm not surprised few parties have had the
appetite to tackle the challenges of bringing it to fruition.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

In the traditional way, each document was managed by a single
controlling application. Thus, you had word-processing documents
managed by a word-processing app, spreadsheet documents managed by a spreadsheet app, etc. To create a new document of the right type, you
had to launch the right app.

Sounds like Emacs org-mode.
--
Dan Espen
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Dan Espen <dan1espen@gmail.com> writes:

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

In the traditional way, each document was managed by a single
controlling application. Thus, you had word-processing documents
managed by a word-processing app, spreadsheet documents managed by a
spreadsheet app, etc. To create a new document of the right type, you
had to launch the right app.

Sounds like Emacs org-mode.

I was thinking the exact same thing.
--
Regards,
Jonathan Lamothe
https://jlamothe.net - PGP: 9CF2CE03EBF08E8C8B66C3660198463E3CF3FFD1
I N++ Unicode
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

John Ames <commodorejohn@gmail.com> wrote:

It's been a minute and I never dug into the nitty-gritty, but AFAICT it
was a bit of both. I don't doubt vendors' instincts for lock-in played
a part, but I think it was as much (if not more) that creating a robust
& extensible framework for tying together multiple disparate-but-inter- operable components is Hard, Actually.

It's easy to *say* "the spreadsheet part," but in order to implement
that in a real-world context you have to define what a spreadsheet is,
and that entails defining all the things it *isn't.* Say you discover
later that there's a need for [spreadsheet] to include XYZ frobnitzen
that weren't part of the initial spec (or, with commercial interests involved, that Marketing *decides* there's a need.) Now the conceptual
scope of [spreadsheet] is larger than the [spreadsheet] standard...

Do you let vendors go ahead and implement it in their own [spreadsheet] components however they will? Then you lose interoperability, since XYZ
will be limited to the internal scope of a [spreadsheet] and get lost
if you try to bring it across into something else (the old "rich text
doesn't copy/paste correctly" problem.)

Do you let vendor X take the lead, and everyone else copies their work?
Then XYZ is liable to pick up their idiosyncracies, and may not mesh
well with other vendors' way of doing things.

Do you try to wrangle a standards body into defining the XYZ extension?
Then you push back the implementation of XYZ months or years, all while
the *need* for XYZ goes unfulfilled in the meantime - *or* you move
ahead with one of the first two options and try to reconcile standard & implementation after the fact, which inevitably turns into a clownshow.

And the mechanics of implementing "very many arbitrary interoperable components" as a design strategy are their *own* challenge, especially
if they're sharing a process space or otherwise have the means to make
Stuff happen automagically. Just look at how many security issues OLE, ActiveX, and VBScript have been responsible for, and that's largely
within the range of *one vendor's* products.

It's a lovely *idea,* but I'm not surprised few parties have had the
appetite to tackle the challenges of bringing it to fruition.

Computer Concepts products for the Archimedes had an interesting take on it. You had separate editors for equations, tables, etc which were standalone
apps. When you wanted to insert a new table, it would spin up the table
editor app and let you edit it, and insert the table back into the document when you saved it.

The neat trick was that their file formats were based on extensions of a generic vector graphics format that was common across the OS. Extensibility was a supported part of the original design, a bit like HTML (but a binary format).

That meant apps could trivially display those tables, equations, etc even if they didn't know anything about the metadata. You could only properly edit them in the respective app, although it was possible to open them in the standard vector editor - I think the editor would propagate the extended
tags but not know how to modify them. If you reloaded the edited file into
the table/equation/etc editor then the vector part would be regenerated and edits in the vector graphics part would be lost.

Today you'd probably do something similar with SVG, with extra tags for the structured data that SVG editors don't understand. Perhaps you could merge
the semantic parts of HTML with the display parts of SVG? After all, we already have HTML tables, MathML, OOXML, etc.

Theo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 18 May 2026 17:34:00 +0100 (BST), Theo wrote:

Computer Concepts products for the Archimedes had an interesting
take on it. You had separate editors for equations, tables, etc
which were standalone apps. When you wanted to insert a new table,
it would spin up the table editor app and let you edit it, and
insert the table back into the document when you saved it.

Apple had that sort of thing before it went in for OpenDoc. In 1991,
the new Mac OS, System 7.0, introduced a feature called rCLpublish & subscriberCY, which allowed this sort of hot-linking between apps.
High-level interprocess communication used the rCLAppleEventsrCY
mechanism, also new with System 7.

I donrCOt think publish/subscribe was very popular, though.

The neat trick was that their file formats were based on extensions
of a generic vector graphics format that was common across the OS.

The Mac had QuickDraw graphics from the beginning, with a standardized rCLPICTrCY clipboard type that could be cut/copied/pasted between apps.
Not exactly a full vector format, and not even resolution-independent,
but a big advance on anything else available (at anything approaching reasonable cost) in 1984.

Today you'd probably do something similar with SVG, with extra tags
for the structured data that SVG editors don't understand. Perhaps
you could merge the semantic parts of HTML with the display parts of
SVG? After all, we already have HTML tables, MathML, OOXML, etc.

Think of SVG, roughly, as layout+presentation first, content second.
Whereas HTML is content first (or at least content structure first), layout/presentation second. And then thererCOs CSS, which provides the layout/presentation details for HTML -- but not to the level of exact
placement that SVG allows. So thererCOs this little gap in functionality between the two, by design.

If you look at the things being done with web-based apps nowadays, I
think what yourCOre talking about is already being routinely
implemented, in terms of HTML documents with embedded objects of SVG
and other types, with user editability even.
--- Synchronet 3.22a-Linux NewsLink 1.2