More Motivation for new Markup

I (Ward) find I have written a lot of scripts that fetch content from wiki, transform that content usually by cross-referencing things in some application specific way, then emitting something like a summary on the page or sometimes opening a new page with lots of details.

I launched into this project by summarizing my intentions and then translating a couple of recently coded scripts into what I could imagine as a pretty handy "markup" for a new plugin that could replace these scripts. There are a few things a plugin can do that we don't allow of scripts. This is because javascript is too powerful to be trusted without community examination.

We don't worry about plugin markup because plugins interpret the markup step by step and won't do steps considered dangerous. I'm thinking a new plugin with markup sufficiently powerful to do the translating I've been doing but safe enough to be trusted solve some usability problems we currently have.

Here is a current problem: It is hard for the Solo plugin to know when the transformation scripts have finished their work. We ask folks to run the scripts, wait until they are done, then open the Solo Lineup Browser which does everything except open the Solo pop-up window. One has to click a second button, the "Open in Solo" button on the Solo Lineup Browser page.

I'm thinking, why not just have the script offer the "Open in Solo" button when it is good and ready. But I can't do that now. We can't trust html scripts loaded from random pages to be opening the pop-up window. But we could trust a new plugin that carefully runs transformations step by step and offers the pop-up when it is good and ready.

.

There are a couple of words we use that have many interpretations but one in particular is cast as a plugin. That would be "transporter". We borrowed the word from Star Trek. It was the tech that moved people between alien environments.

Our use case was David Bovill who wanted to write plugins using his HyperTalk style language but have it work within our Javascript environment. If you dropped a page on the transporter it would send it to David's server where he would compose a page in response. This worked because the page json was well defined and not specific to any particular language.

This plugin provides interactive access to remote services that can read content you drop and create from it useful pages that appear ready to be saved or used at one's discretion.

In my brief search for prior art I found the kind of thing I wanted to write was sometimes called a "transformer". The distinction that I see between the two ideas is that the transporter moves a page to an alien environment and another related page comes back.

For the transformer I want to read a half-dozen well defined formats and produce right in the transformer new content in some other well defined format. The advantage of making this a plugin is that they have a lot of input and output formats to choose from.