Keyman cross platform input methods system running on Android, iOS, Linux, macOS, Windows and mobile and desktop web
Find a file
2018-10-02 10:53:07 -06:00
docs Document my thoughts on web worker communication. 2018-10-02 10:30:02 -06:00
.gitignore Initial commit 2018-10-01 14:06:26 -06:00
index.js Extract method: _recordPromise(). 2018-10-02 10:53:07 -06:00
LICENSE Initial commit 2018-10-01 14:06:26 -06:00
lmlayer.js kind -> method, and other clean-ups. 2018-10-02 10:46:00 -06:00
package-lock.json It was the threads, man. 2018-10-01 15:33:51 -06:00
package.json It was the threads, man. 2018-10-01 15:33:51 -06:00
README.md Document my thoughts on web worker communication. 2018-10-02 10:30:02 -06:00
test.js Not sure why there's still stuff in the event loop, but whatever. 2018-10-01 15:30:01 -06:00

Keyman LMLayer prototype

Prototype of NRC language model layer for Keyman.

I'm developing and experimenting with the API and how different API designs will practically work.

Current status (Tue Oct 2 09:45:10 MDT 2018):

  • Developing communication protocol between keyboard and Web Worker.

Communication protocol between keyboard and asynchronous worker

Sequence diagram of obtaining a prediction

We have decided that everything to the right of the KeymanWeb will be in a Web Worker. However, communication can happen only through postMessage(payload) commands, where payload is a serializable object (via the structured clone algorithm).

What serializable object can we send that will adhere to the open-closed principle?

The idea is to use a discriminated union. The protocol involves plain JavaScript objects with one property called method that can take a finite set of string values.

These string values indicate what method should be called. The rest of the properties in the object are the parameters to method.

{
    method: 'predict',
    // method-specific properties here
}

See also: XML-RPC

Tokens

Tokens uniquely identify an input event, such as a keypress. Since Keyman should ask for an asynchronous prediction on most keypresses, the token is intended to associate a prediction and its response with a particular input; Keyman is free to ignore prediction responses if they are for outdated input events.

The Token type is opaque to LMLayer. That is, LMLayer does not inspect its contents; it simply uses it to identify a request and pass it back to Keyman. There are a few requirements on the concrete type of the Token:

  1. It MUST be serializable via the structured clone algorithm;
  2. It MUST be usable as a key in a Map object.

It is up to Keyman to create unambiguous tokens that can be uniquely identified through the round-trip process.

In the following examples, I'll use the subset of number values that are interpretable as 31-bit signed integers.

Example

An asynchronous message to predict after typing 'D':

{
    method: 'predict',

    token: 1,
    transform: {
        insert: 'D',
        deleteLeft: 0,
        deleteRight: 0
    },
    contexts: [
        // TO BE DETERMINED
    ]
}