User Story:
User is using their Library in macOS Reader (this is our test environment, any others should work soon too)
User puts on a headset to continue working in their Library.
The user accesses ‘Reader XR’ (through web page or app) and their Document Metadata and Library Metadata is downloaded.
The user can interact with their Library and choose to open any document for reading, changing layout of and annotating.
When done they can put down their headset and return to their traditional computer.
Data Flow:
The data in Reader is in the form of Visual-Meta at the end of all documents and when writing any new Visual-Meta to a document it is also saved in a Document Metadata database.
This Document Metadata database will be stored in the form of JSON.
All the user’s metadata will be syncing with a server.
When done, the Library Metadata is transmitted back to Reader macOS (or equivalent), as well as any changes to Document Metadata (such as annotations being added or removed).
Definitions:
‘Computer’ means desktop or laptop computer, in other words computer in the traditional sense.
‘Headset’ means VR/AR/XR headset running webXR Reader software.
‘Server’ means software which provides continual access to data, via HTTP.
’Storage’ means software which stored document metadata (in List format) documents and library context metadata on physical storage.
‘Document Metadata’ includes core visual-meta, highlighted text and AI and XR generated temporary Visual-Meta.
‘Documents’ means initially PDF but will support any format.
‘Context Metadata’ means data which describes a use and/or display of the collection of documents and their associated metadata. This can be a single headset in a single real or virtual environment where documents are assigned positions etc., and it can mean the same headset in a different virtual environment or Augmented Reality environment etc.
‘Reader XR’ is the software to be developed for XR headsets.
Bjorn’s notes
If we think of the data store as the authoritative source of user’s data, what we are faced with is essentially a replication problem. That is, whenever an application that uses data from the datastore starts up, it wants to know “what has happened since the last time I was connected to this store? What’s new, what’s gone, and possibly what has changed. Of course this can be refined to “what has happened with the subset of data that this application on this device is interested in”.
Change is difficult to deal with, which is why immutability is a great approach: rather than allow data records to change, you just add new versions of them. A given version of something is never allowed to change. This will ensure you keep any references to previous versions intact, while providing a mechanism for discovering that the version you have has been superseded by one or more newer versions. It also means replication is simple – you either have the document with id abc123 version 1 or you don’t. There is no need to compare it to anything to determine which version it is.
It makes sense to make the version part of the ID you use whenever referring to a piece of data. So for instance abc123@1, abc123@2 etc. (This is essentially how some software systems manage dependencies: you use both the unique name of the dependency and its version). You can also create shorthands whenever you are interacting with the user. For instance abc123@latest to instruct the system to “figure out what the greatest version number of abc123 is and then use that when we store the reference”.
When the Headset connects for the first time it will of course want to download all the metadata. On successive connects you want to know “what has changed since the last time” and then only download the changes. You could do this by timestamp, for instance. The response can either be all the metadata or just the IDs of the versioned metadata items (allowing the Headset to determine what it actually needs to download).
Also: Reader can announce itself on local network using Zero-configuration networking.