|
|
|
|
|
|
by al_ak
2561 days ago
|
|
|
I know Alaska used Lotus Domino (a web framework with Lotus Notes as the development stack) in the late '90s to put some of their services online (job postings/electronic applications is the big one I remember). It worked pretty well at the time, but finding Lotus Domino developers isn't easy since it's such a niche product |
|
|
All the Notes app-documents authored by a given individual will burn in, as the API-backend endpoint for that app-document, the particular Domino server corresponding to their own originating email server. (It's sort of as if you opened Excel and it automatically detected your company's on-prem k8s cluster, and then installed a workload there for your Excel sheet to reach out and talk to, even when you share the spreadsheet around outside of the organization.)
Domino was (is?) a pretty cool and ahead-of-its time piece of tech. In modern terms, it's basically "Firebase as an on-prem appliance." Client applications (i.e. Lotus Notes app-documents) define the schema on connection, rather than there being an explicit out-of-band database/table creation step; and the API handles syncing state between a local representation of the app-document's database and the server's (multi-user shared) representation of same.
Or, to draw a parallel from another point in design-space: Domino is like iCloud's Core Data sync, but multi-user (where the data on the server is just an event stream, it's the client's job to linearize+reduce the event stream into a new mutable state, and users take the user credentials that events have been signed with into account in deciding which events have CDRT precedence over which.)
Or, for a "ridiculous, but not exactly wrong" analogy: Domino is a private blockchain, and the app-documents loaded into it are smart contracts.
Or you could look at it like CouchDB's design documents, with better sync.
Really, there are a lot of things you can sort of describe it as, but nothing that perfectly lines up.