Specification Ideas

Specification Ideas / Work in Progress

• The actor-based widget toolkit should be integrated in the used actor library in a way that it uses its own, closed actor system, i.e. sending messages between parts of the toolkit stays in that system, sending messages from the toolkit to the outside world leaves that system and sending messages from outside to the toolkit enters that system.

  Implications of this closed system are:

  • Usage of any part of the toolkit implicitly uses the concurrency model inherent to the toolkit. This avoids misuse which may e.g. freeze the user interface.

  • Sending messages from parts of the toolkit outside implements what usual toolkits need to explicitly implement by so called workers which execute time-consuming background tasks. With the actor model in mind this process becomes very obvious and seems very intuitive: TODO graphical representation

• The API should be designed in a way to impose no significant overhead to convert the internal, mutable state of widgets to immutable messages which can safely be passed across thread borders. This can be achieved in one of the following ways:

  • Mutable state is represented by changeable references to immutable objects. Due to its immutability the state itself can be passed around as messages without any conversion needed.

  • Mutable state is represented by references to mutable objects. Depending on both how these mutable objects themselfes expose their state and whether or not they on a whole or only parts of them should be passed around conversion may be needed.

  The API should prefer the first way.

  TODO: Overhead of wrapping immutable objects in message objects?

• Is absolute protection against misuse possible? How can users be prevented from freezing user interfaces by executing time-consuming tasks inside the toolkits actor system? Should the actor system of the toolkit be a black box?

  Implications:

  • all user-defined callbacks would have to be executed outside of the toolkits actor system