Ticket #371 (new Defect)

Opened 7 years ago

Last modified 5 years ago

"Home" workspaces for plugins

Reported by: jri Owned by: jri
Priority: Major Milestone:
Component: DeepaMehta Standard Distribution Version: 4.5
Keywords: Cc: dgf, Malte
Complexity: 5 Area: Application Framework / API
Module: deepamehta-workspaces


A plugin developer should be able to declare a "Home" workspace for the plugin. All types and instances the plugin provide would be automatically assigned to that workspace.

This would provide a reasonable default configuration for workspace-based access control.
Currently 3rd-party plugin developers must care for the configuration manually which is cumbersome.

For the plugins of the DM standard distro there is already such a "Home" workspace, and assignments are created automatically based on the "dm4" URI prefix. This concept could be applied to 3rd-party plugins as well.

Thanks, mre, for this idea!

Change History

comment:1 Changed 7 years ago by jri

  • Milestone changed from Release 4.1 to Release 4.2

comment:2 Changed 6 years ago by jri

  • Milestone Release 4.2 deleted

comment:3 Changed 5 years ago by dgf

  • Version changed from 4.0.12 to 4.5
  • Type changed from Enhancement to Defect
  • Module changed from deepamehta-core to deepamehta-workspaces

At least since the introduction of the Workspace Sharing Mode this is more than an enhancement. There is definitely a need of a configuration mechanismn for the workspace assignment of declarative migrations.

All Topics and Types of a 3rd-party plugin migration are created without any workspace assignment. This implies that nobody can edit any provided plugin topic, e.g. the default configuration of the mail plugin.

IMO there are several approaches to resolve this assignment:

  • The first and simplest form is hard-coding the assignment of an existing workspace like System or DeepaMehta for all plugins.
  • Slightly better is a plugin specific configuration that defines and references a workspace in plugin.properties.
defaultWorkspace = DeepaMehta
requiredPluginMigrationNr = 2
pluginPackage= org.digitalmemex.bootstrap
importModels = de.deepamehta.files
  • Finally the most dynamic, and my favourite, is the creation of workspaces in a migration itself. This could be look like the following example. That migration should create a workspace and reference it in the Repository type definition. The second type SimpleTypeExample references the existing System workspace.
    workspaces: [ # <<< create your own workspaces
            name: "DigitalMemeX",
            uri: "dmx.workspace"
    topic_types: [
            value: "Repository",
            uri: "dmx.repository",
            workspace_uri: "dmx.workspace", # <<< use the created plugin workspace
            data_type_uri: "dm4.core.text",
            index_mode_uris: [ "dm4.core.key", "dm4.core.fulltext" ]
            value: "SimpleTypeExample",
            uri: "dmx.example.type",
            workspace_uri: "dm4.workspaces.system", # <<< use the default system workspace
            data_type_uri: "dm4.core.text",
            index_mode_uris: [ "dm4.core.fulltext" ]


But no matter what variant we choose, there should be a usable default behavior for all plugins without an explicit workspace assignment.

comment:4 Changed 5 years ago by dgf

The configuration of the mail plugin is a bad example, as long as it uses the magical handled dm4 URI prefix.

comment:5 Changed 5 years ago by jri

My 2 suggestions would be:

  1. The approach you've described as your favorite: extend a declarative migration by a "workspace" information. Just with a little difference: I would not add the workspace_uri property on a per-object basis but rather establish a "workspace context" for an entire set of objects. That is roughly:
        workspace_uri: ...,
        topic_types: [...],    # format as it is now
        assoc_types: [...],    # format as it is now
        topics: [...],         # format as it is now
        associations: [...]    # format as it is now
    The workspace would apply for all the objects declared in that context. We could decide weather a single migration would contain a single workspace context or multiple ones. (I tend to a single one.) And yes, the developer must have the opportunity for both, creating a new workspace, and referring to an existing workspace. (This detail is not expressed here.)

My rationale here is to avoid extending the DeepaMehtaObjectModel -- that is also the basis for JSON parsing -- by a "workspace" information. I want keep the object model small and see "workspace assignment" as a separate aspect. (Anyways, this might be seen as an implementation detail.)

  1. We could consider the quite different approach that is sketched out in the original ticket description. That is we could generalize the special meaning of the "magic dm4 URI prefix" :-) and make a principle of it: expressing an object's workspace affiliation explicitly by its URI prefix.

That would mean that DM maintains a global table that maps URI prefixes to workspace URIs, and that plugins can add entries to that table (either directly in the declarative migration or via plugin.properties).

dm4: dm4.workspaces.deepamehta
dmx: dmx.workspace
ff: net.freifunk.workspace
ffa: net.freifunk.admin.workspace

While not knowing if this approach would be practicable for all application scenarios I like its "explicitness" though. And it feels kind of "natural" to me as the general purpose of URIs is to establish namespaces (for organizing the cyberspace), and this is per-se similar to DM's workspace concept (for organizing content and user access). An evidence for semantic affinity here might be the common term "space" as in "namespace" and "workspace".

As you see at the moment I like the 2nd approach. What do you think about it?

Once agreed, on whatever approach, I could realize it quite quick and release it as part of the upcoming DM 4.6 release.

Thank you very much for your input on this pressing issue!

Last edited 5 years ago by jri (previous) (diff)
Note: See TracTickets for help on using tickets.