RFC: POC/interface suggestions for rudimentary lightweight bash-only "extensions and content management"

[Lex Sulzer]

Further ideas suggestively partly-implemented by dataspects/mediawiki-manager (bash-only):

• Install/disable/enable extensions:
  • install-extension.sh
  • enable-extension.sh
  • disable-extension.sh
• Inject "initial default ontology":
  • inject-local-WikiPageContents.sh (i.e. content provided in WikiPageContents/)
• Inject GitHub-based ontologies:
  • inject-ontology-WikiPageContents.sh (i.e. content provided e.g. by https://github.com/dataspects/dataspectsSystemCoreOntology)

[Yaron Koren]

Hi Lex,

Thanks for sending these suggestions. I actually disagree with all of these (for different reasons), but it's good to talk about them here. This mailing list could well be a more efficient way to discuss things than our weekly meetings, so I'm glad to have discussions here, in parallel with our meetings.

So, there are two aspects to this proposal: handling extensions, and handling "ontologies". Extensions first:

Here is the way I've been envisioning handling the installing and disabling of extensions (and skins): the "Canasta" installation would of course include a LocalSettings.php file, but that file might look something like this:

require_once( 'MyBeforeSettings.php' );

...DB settings, other standard MW configurations...

if ( ! in_array( 'ParserFunctions', MY_DISABLED_EXTENSIONS ) ) {

   wfLoadExtension( 'ParserFunctions' );

   $wgPFEnableStringFunctions = true;

}

if ( ! in_array( 'VisualEditor', MY_DISABLED_EXTENSIONS ) ) {

  wfLoadExtension( 'VisualEditor' );

}

...and so on...

require_once( 'MyAfterSettings.php' );

This LocalSettings.php file would be expected not to be touched by administrators in any way - maybe it should actually be made read-only. Only updates of the entire "Canasta" installation would modify it. Then the two truly "local" files, MyBeforeSettings.php and MyAfterSettings.php, would be used by administrators to do all their configurations. Extensions could be disabled in the "Before" file, by adding extension names to the MY_DISABLED_EXTENSIONS array (and there could also be MY_DISABLED_SKINS). And changes to extension settings would have to be done in the "After" file. The addition of new extensions (or skins) could be done in either file - maybe it doesn't matter.

(By the way, it doesn't have to be called "My" - that's just my idea. Although of course that naming makes some sense.)

The advantage of this kind of system over one where extensions are installed/disabled via scripts is that it's a lot simpler: there are "Canasta" files (which are not to be touched) and there are "my" files (which can be freely modified), and there is nothing in between. There is no "state" of the installation that either the administrator or the code has to keep track of.

(One complication to this, which I think we did talk about a little before, is that there might have to be two extension directories, and two skin directories: /extensions and maybe /myextensions, and /skins and maybe /myskins. Hopefully there's a way to set that up so that wfLoadExtension() and wfLoadSkin() would always go to the right directory.)

Now, the other part, "ontologies": first of all, I usually call these "data structures"; I think that's a more accurate name than "ontologies", because I don't think an ontology usually includes a data entry part, like a form. Anyway, regardless of the name, I prefer the approach taken by the Page Exchange (PX) extension for this - install wiki pages through the wiki interface, not from a script. The advantage of the Page Exchange approach is that it's easier for an administrator to understand, and control, what's going on with these wiki pages through a special page rather than on a command line. Let's say that you want every installation of some "Canasta" product to include two packages of wiki pages: that "meta-ontology" (if I understand it correctly) you have defined on GitHub, plus a package that defines a BPM data structure. If everything is installed via PX, the administrator can see at a glance that there are two distinct packages installed on the wiki - and they can remove one or both, or update them if new versions show up. On the other hand, if everything was installed from the command line, then an administrator (who may or may not be the same admin who did the installing) has no easy way to know where any page on the wiki came from - which package it comes from, or even if it came from a package at all.

Now, one advantage of a script is that it can be run automatically during the installation - so that, the very first time someone goes to the wiki, the data structure(s) are already there and there's never a "blank page problem". However, I think this could be done via PX as well: PX right now lacks an API, but one could certainly be added to it, so that the script that installs Canasta could, at the end, go to the API URL to import whatever package(s) are needed via PX.

Those are my thoughts, but I'm looking forward to your (or anyone else's) opinions.

-Yaron

--
You received this message because you are subscribed to the Google Groups "Project Canasta" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-canas...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-canasta/48641cb6-2b5e-4223-9230-7266eba3c1c0n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

WikiWorks · MediaWiki Consulting · http://wikiworks.com

[Lex Sulzer]

Hi Yaron

Please find some comments inline.

 

Here is the way I've been envisioning handling the installing and disabling of extensions (and skins)...

• I had already discovered the discussion you initiated (https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Extension_management_with_Composer)  and I like the idea of $wgDisabledExtensions and the separation of concerns with the help of "required" files. What's your suggestion to provide "easy" ways to install/disable/enable extensions and skins, i.e. something akin to my envisaged "Enter extension name to install/disable/enable:" based on vetted catalogues of "certified" (sets of) extensions and skins?

Now, the other part, "ontologies"...

You raise good points. Two comments here:

1. On https://wiki.dataspects.com/wiki/Category:Ontology you see how I keep track of which data structures "provide" which pages, i.e. "{{#ask:[[Subcategory of::Category:Ontology]]" yielding https://wiki.dataspects.com/w/index.php?title=Template:OntologyComponentsTable&action=edit. The limitation of this "wiki-onboard-tooling"-based approach is of course that it forgoes data structure components that are not pages in a categorizable namespace.
2. I was wondering whether you were planning to add API endpoints to PX, so looking forward to your development here.

See you later!

[Yaron Koren]

Hi Lex,

As far as extensions and skins: I don't think we've talked before about the idea of "certifying" certain extensions and skins, though I guess that was a component of the "Sunflower Distribution" project and maybe others. Personally, I don't see a need to do any certification: the way I see it, we (or really, the people who make any specific "product") are responsible for the code and wiki pages that go into that product, and nothing else - additional extensions and skins are up to the administrators of the wiki. I'm not sure that we collectively even have the expertise to determine which extensions/skins, of the thousands available, are good or not - let alone whether we can always make good decisions when there's conflict of interest and so forth involved. Creating some form of vetting is so far outside the scope of this project, and I think it makes sense to keep it that way.

There's also the issue that (if I understand it correctly) every vetted extension would need some sort of defined handling so that the "Canasta" code would know how to download and install it. Again, that seems like work I would rather not add for us.

One option, for people who want to have some set of "approved but not included" extensions and skins for a product, is to have those extensions and skins included in the product but disabled by default - that seems like a reasonable, lightweight approach.

-Yaron

--

You received this message because you are subscribed to the Google Groups "Project Canasta" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-canas...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/project-canasta/b18411b8-78c8-4455-8eef-7ed909a478d3n%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Yaron Koren]

I just re-read my email - just to clarify, when I wrote, "Creating some form of vetting is so far outside the scope of this project", I meant, "So far, creating vetting has been outside the scope", rather than "Creating vetting is very far outside the scope".