Skip to content

Change semantics of restrictions #7

Description

@feldentm

The current implementation of restrictions reflects the semantics of SKilL, i.e. they are serialized, can be checked, result in exceptions and implementations is an optional feature. This does not make sense as it inflicts a runtime overhead and is not useful in practice. Thus, the concept should be reworked to a pure runtime check that results in a list of violations. Serialization should be removed completely.

If a tool requires restrictions to be met as a precondition, it should check so as first step and provide an adequate reaction if there is a violation. "Adequate action" can mean a lot of things based on the tool's usage context.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions