I have been offline discussing some interest for a more flexible version of SWISH.
Hopefully starting a “cabal”. How it works - you opt into the Cabal, you get a voice in the outcome. You also hopefully can commit to providing 2 programmer days (or more) working on the consensus. If you cannot provide any days/code we still need to understand your needs!
As a Cabal we generate a consensus roadmap of things we’d like to see in SWISH.
As a start towards that consensus, it seems we’re mostly interested in changes to the core code that make building our own specialized version easier, rather than ‘new features’. Our vision is that folks who are building specialized versions, like cplint, LPS, etc., can pull from the swi-prolog SWISH, do some git magic to integrate with their own changes, and not have to maintain a SWISH fork - though our start is simply to make that true for a wider range of users.
A word about consensus. It doesn’t mean we agree about everything. It only means we are able to find some things we all agree would be nice. If we all agree doing X would be good, but some of us think we should Fix problem3 with solution1 and some with solution2 and a minimal amount of discussion doesn’t resolve that, then we just go do X. We’re looking for the maximal set of commonly agreed changes. That minimizes time lost in discussions and prevents conflict.
We’d like to get your feedback and thoughts. As a start, in the area below please add a section with your name/company and your pain points in integrating your special version with SWISH. After that, we’ll arrange a zoom meeting and hammer out things we can agree would be nice, then get the work divided up, and we’ll all have a much nicer SWISH!
Individual Needs
Miguel Calejo
Very top in my list is: documentation on customization and deployment. It would be great to have a guide. Like most (I guess) I end up searching SWISH sources for recipes etc.
Anne Ogborn
I’m not actively maintaining a SWISH fork, but have in the past. I’m here mostly helping organize, but will commit to 2 days programming.
My wish list, based on past things:
Overall architecture for plugging in more changes without modifying the core.
- More control over visual styling
- Pluggable cell types
- More configurable file storage
- Examples in a submodule so we can swap our own
- Less awkward ways of interacting with javascript.
I also have some complaints about UX stuff - not in our cabal’s mandate, but we might examine if I’m not alone.
- Make the annoying ‘restore’ / tabs functionality an optional behavior (talked with Jan about this, it’s needed for the :- include/1 and I’m reluctantly agreeing it should stay).
- Make the chat system work in a saner fashion.
- A better way of finding files
Jacob Friedman
WASM can spawn Pengines and, using WebRTC (eventually UDP Multicast/Broadcast a la QUIC/HTTP3) perform some cool RPC calls. One may also load .pl modules into a WASM environment. In my opinion, adding more styling with javascript sugar is just one way to further separate the UI with Javascript… when it really should be prolog controlling the DOM at the high-level. Prolog can insert and load libraries when needed at the WASM level - manipulating the DOM & JS Heap as it evaluates user input. At this point I’m investigating some possibilities between libp2p and Paxos with TIPC… this can have some great benefit with real-time interops.
Douglas Miles
I am maintaining a swish fork that does many new things but I find it a struggle every month keeping up with all the other forks that also do additional wonderful things.
Here are list of some authors whose forks I am consuming: Jan Wielemaker(SWISH!), Miguel Calejo (LPS), Fabrizio Riguzzi (CPLINT, Trill-on-swish-On-Cliopatria), Riccardo Zese (Trill-on-swish)… (I have been combining at least three of Fabrizio’s different forks)
Functionality I have Completed:
- Shared editable Folders/Files that are accessible by users:
:- use_module(shared(dmiles/project1/mod')).
- Mapping of user’s Google Docs/Drives onto SWISH’s available files
(also works for Dropbox) … The idea here is the user can mix the server shared folders with local files by using the cloud services.
:- use_module(shared(dmiles/gdrive/localcomputer1/project2/modA)).
File browser
- SWISH Ability to edit any filetype CodeMirror allows
(Opens in the same place programs/notebooks open)
Also allows files to be saved after edits.
- …. Lots to list here …. (Still doing so)
-
:- use_rendering(html).
to allow direct term-ified HTML writing
Inherited/Merged functionality from Forks not maintained yet in SWI:
(The authors of these modules will hopefully have their own wishlist… listed below are just things i copy/used from existing forks)
…. Lots to list here …. (Still doing so)
-
- Rendering: Toggling Between Cliopatria RDF view to SWISH defaults
NEEDS REDO - Cliopatria Menu Navigator as well as all the existing Cliopatria CPACK tools
NEEDS REDO - Profiles (RDF11 vs RDF)
- Extra Semweb examples like
SWISH -- SWI-Prolog for SHaring - (also see GitHub - friguzzi/trill_on_swish: Cliopatria pack for trill (this is a CPACK))
- Rendering: Toggling Between Cliopatria RDF view to SWISH defaults
-
Trill-on-Swish (Non-CPACK)
- Enumerating Extra Help files into Help Menu
- TRILL , Probabilistic TRILL profiles
- Extra Trill examples
-
- Dismissible header
- Profiles (LEMUR, ALEPH, CPLINT, PHIL)
- Extra examples
-
Early CPLINT
- Extra file type editing like LPAD (needs redone ?)
-
LPS SWISH (Bitbucket)
- Timeline/Animation renderers
http://demo.logicalcontracts.com/example/lpsExamples.swinb
Logical Contracts -- Alpha Demo -
:- expects_dialect(lps).
Is vetted inside SWISH temp modules
- Timeline/Animation renderers
My further wishlist:
That we have an “Official Fork” that may contain all the projects examples
And wild features combined! into a “Franken-SWISH”
(We can still have the small/tight SWISH that is official one we have now)
-
Ideas: Buttons to Include/Disclude Franken-SWISH content/adornments ? TODO
-
Ability to inspect/browse PACK_INFO (currently only a PLWEB feature) TODO
-
Ability to create Editor pages (tabbed.js) with
<iframe>
s TODO -
“Submenus” from ‘swish(examples)’ disk layouts TODO
-
Separate Cliopatria’s aliases of “config-available” and “config-enabled” from SWISH’s (Rename one of them?) NEEDS REDESIGN
-
(My TODO) Making sure that I don’t need to change SWISHes code when I swap out for a different file system browser lib. For example I want to replace elFinder’s Javascript system with Thelia’s Javascript directory browser. How it works now is pretty much I use javascript to communicate to swish what filesystem content is being used/updated … sometimes prolog will actually pull the source text from the URL that is supposedly mapped to the disk… etc TODO
-
The ability to set a long running process and destroy it later in a “Process/Thread manager” TODO