LionWeb Roadmap, Releases, and History

We’ve decided^[1] to specify protocols only by their conceptual features. The first such protocol will be the Bulk Repository access API. It is used to store and retrieve nodes in batches at the moment of invocation.^[2] It is intended for CRUD operations on (larger) sets of nodes, and enables integration with "simple" editor (i.e. no real-time collaboration). Additionally, this API allows to list the available Partitions, get Languages known to the repository, and request unused node ids.

As described in our reference architecture, via delta protocol a client receives an initial snapshot similar to the bulk case. Afterwards, the client continues to receive changes (aka deltas) from the repo; it also writes back changes continuously.^[3]

We intend to support several common language (workbench) functionalities via derived models. For each functionality, LionWeb would define a base language. Any implementation might use these base languages directly, or define its own extension languages.

As an example, LionWeb’s validation base language might define concepts for Error, Warning, and Info. My validator implementation would create instances of Error and Info, but also include a custom compiler-based validation language that defines GeneratorWarning and CompilerWarning as specializations of Warning. A client that only knows about LionWeb’s validation base language can process both of the specialized warnings in a generic fashion. Another, compiler-aware client might display GeneratorWarnings differently than CompilerWarnings.

Base language candidates are typically common language functionalities that might be expensive to calculate. This includes:

Different users might have different level of access to the whole repository, or parts of it. Some users might have read-only access (e.g. via public web), whereas others can write to the repository.^[7]

A repository might support version control and/or live collaboration of users.

The repository might have a version control backend like git, or support live collaboration like Google Docs.^[8]

A repository might support locking the whole repository, partitions, or subtrees. The lock might be established with optimistic or pessimistic locking strategies.^[9]

A repository A might access a different repository B, and provide B's contents to A's users. The two repositories might be synchronized on a regular schedule, or continuously.^[10]

A global index of (fully qualified) names can be very useful for any kind of name lookup, for example in parser-based name resolution, scoping, or auto-completion.^[11]

Different clients might refer to the same node by different ids. The repository might support them by automatically mapping between the repository’s internal id, and the id known to each client.^[12]

Support a common way how to handle language migrations, e.g. by specific messages like "I’m about to migrate this partition", or "You must not use language X in a version older than abc".^[13]

Given a valid input with invalid text at few places, both tolerant parsers and projectional editors can provide a "mostly correct" AST representation. Internally, they have some way of keeping the invalid text around. We could support a standard way to store such invalid text in the repository.^[14]

Calculating the difference between two sets of nodes is common, complex, and potentially expensive task. It might be useful to have a standard format to exchange the difference, and the Delta protocol could provide a solid base.^[15]

More complex filters for Specifying bulk protocol and/or Delta protocol might help saving communication overhead. For example, I might query via bulk only for Dog concepts, or only receive delta updates for Dogs with furColor == red.^[16]

In source code it’s very common to comment out a part of the contents. We might come up with a standard way to support similar functionality to comment out some nodes.^[17]

A user might define their own DataTypes and support their (de-)serialization.^[18]

We might add some Annotations to the built-ins language, e.g. range constraints on integers, implementation per platform, @Deprecated, etc.^[19] Another useful set of annotations would be review comments: For any kind of collaboration, it’s very helpful for reviewers to attach their remarks directly to their context — think of the blue speech bubbles in the right margin of a Word document.^[20]

For some use cases (e.g. merging), it might be useful to know that the order of features does not matter.^[21]

In most advanced DSLs, we want to evaluate or "execute" models directly, i.e. without intermediate generation step. Interpreters can be implemented in various ways, but usually have a very standard interface.^[22]

Most modeling systems want to create some artifacts from the model contents, for example source code, documents, or images. This interface can be standardized to receive some input nodes, maybe some parameters, and result in one or more files.^[23]