George wants subwikis to be up-to-date in order to plan his activities transversally.

[Christopher Mann]

Hi all,

Would anyone have any comments on the below use-case?

George wants subwikis to be up-to-date in order to plan his activities transversally.

GeorgeGeek is someone who uses an iPad to edit wikis offline. Each wiki is topical, and George can share entire wikis with contacts. It is also easy for George to treat each subject as a separate wiki.

Acceptance criteria is :

1. GeorgeGeek can modify a sub-wiki file
2. GeorgeGeek can modify a meta-wiki file
3. GeorgeGeek will consult the sub-wiki tiddler updated from the meta-wiki file

Implementation ideas :

Get an Android tablet and do the following, or write a new iPad app that could do the following, or get an iPad developer to modify his or her code for the following:

Create an WikiAsPlugin plugin. Exporting a wiki as a plugin will effectively allow the subwiki to be loaded into the meta wiki without having to restart either a node-js instance nor need to duplicate tiddlers in a current wiki file.

WikiAsPlugin would mainly have an export function. The exported plugin would then replace the currently installed plugin with fresher content. Other functions could be :

• viewing changes to shadow tiddlers
• exporting changes from shadow tiddlers on meta-wiki
• importing changes from meta-wiki into sub-wiki

George, being a geek, would GIT-version the wiki-as-a-plugin and sychronize it with a node-js instance, etc. 

[Tobias Beer]

Hi George, err Christopher :D

 

George wants subwikis to be up-to-date in order to plan his activities transversally.

Does "transversally" mean independently, simultaneously?

GeorgeGeek will consult the sub-wiki tiddler updated from the meta-wiki file

What exactly does George do here?

What does "updated from" mean?

Create an WikiAsPlugin plugin.

Perhaps useTinka?

I still haven't gotten to play more concretely with the idea of swarms, i.e. more "losely defined bundles of tiddlers", plugin-like packaged.

Exporting a wiki as a plugin will effectively allow the subwiki to be loaded into the meta wiki without having to restart either a node-js instance nor need to duplicate tiddlers in a current wiki file.

Ideally, node will at some point not need restarting the server.

 

WikiAsPlugin would mainly have an export function. The exported plugin would then replace the currently installed plugin with fresher content.

Via drag+drop update?

• viewing changes to shadow tiddlers

core feature => look at plugin => observe which plugin tiddlers are overwritten

• exporting changes from shadow tiddlers on meta-wiki

perhaps the right predefined-filter under "advanced search" will do to get "all from plugin X" that are "not shadows"?

• importing changes from meta-wiki into sub-wiki

Mhhh, why not edit the subwiki?

After all George, wants it packed and redistributed back to his meta wiki, not having to figure out what overwritten shadows to eventually delete in the Meta Wiki and when, etc.

George, being a geek, would GIT-version the wiki-as-a-plugin and sychronize it with a node-js instance, etc. 

So he does use node, after all. Then I would perhaps recommend not to endeavour this in-browser approach at all... but I can see how editing on a tablet asks for a way to get those updates from in-there synced back out-there, i.e. into node,

The layman's approach could be: do edits and save them somewhere else, e.g. a backlog in, say, Trello. From there, merge them into those "master wikis" manually.

Best wishes,

Tobias.

[Christopher Mann]

Tinka would work if it would by default export the whole wiki with the filter [!prefix[$]] as a plugin. As Tinka stands, checking each checkbox is a too troublesome.

Here is a WikiAsPlugin approach:

1. George sets up his personal library of plugins
2. A button allows the publication of the current library to that plugin library
3. Any wiki can include another wiki as a plugin through that library

The drawback would be in same-named toddlers being deleted with the deleting or even disabling of the plugin.

[Tobias Beer]

Hi Christopher,

 

As Tinka stands, checking each checkbox is a too troublesome.

I very much agree, without some check-all option, setting it up ain't fun at all.

Here is a WikiAsPlugin approach:

1. George sets up his personal library of plugins
2. A button allows the publication of the current library to that plugin library
3. Any wiki can include another wiki as a plugin through that library

The drawback would be in same-named toddlers being deleted with the deleting or even disabling of the plugin.

I like the approach. Including wikis or just collections of tiddlers in other wikis has always been a very powerful thing. Without it, we'd have no plugins, for one. Currently, we are limited in leveraging this by a sophisticated plugin-mechanism that defies a simple "reuse tidbits" approach and forces a "publish a versioned bundle of codebits and supporting tids for distribution".

When I was referring to "swarms", I meant precisely what you've had in mind. A few tiddlers forming a "swarm" that can move and reinstate in another context as simply as possible. No fuzz, no plugin, designed for content to bundle up and come to life elsewhere.

Right now, what you've got for that is export/import.

Best wishes,

— tb

[Christopher Mann]

author: Christopher Mann

description: TWaaP - TiddlyWikiAsAPlugin - Export filter to create a plugin.

list: readme

plugin-type: plugin

title: $:/plugins/mannfr/twaap

type: application/json

version: 0.0.2-build007

{

    "tiddlers": {

        "$:/plugins/mannfr/twaap/config": {

            "created": "20151107073238652",

            "text": "# Title must follow convention for plugins, such as $:/plugins/author/plugin_name\ntitle: $:/plugins/mannfr/twaap\nversion: 0.0.2-build007\nauthor: Christopher Mann\ndescription: TWaaP - TiddlyWikiAsAPlugin - Export filter to create a plugin.\nlist: readme\n\n",

            "modified": "20151107084740200",

            "tags": "WikiAsAPlugin FromSubwiki",

            "title": "$:/plugins/mannfr/twaap/config",

            "type": "application/x-tiddler-dictionary"

        },

        "$:/plugins/mannfr/twaap/readme": {

            "created": "20151107081239777",

            "text": "This is an additional export filter. Save the file as a .tld, for example for \"All Tiddlers\" in the side-menu. Save the file. Import the file into another Wiki.\n\nTo configure, please change the variables in [[$:/plugins/mannfr/twaap/config]].\n\nFor example, to create this plugin, I did an advanced search with the filter \"[tag[~WikiAsAPlugin]]\" and then simply exported the results as a plugin.",

            "title": "$:/plugins/mannfr/twaap/readme",

            "tags": "WikiAsAPlugin FromSubwiki",

            "modified": "20151107084400261"

        },

        "$:/plugins/mannfr/twaap/plugintiddlers": {

            "created": "20151106222453723",

            "text": "/*\\\ntitle: plugintiddlers\ntype: application/javascript\nmodule-type: macro\n\nMacro to output tiddlers matching a filter to Plugin\n\n\\*/\n(function(){\n\n/*jslint node: true, browser: true */\n/*global $tw: false */\n\"use strict\";\n\n/*\nInformation about this macro\n*/\n\nexports.name = \"plugintiddlers\";\n\nexports.params = [\n\t{name: \"filter\"}\n];\n\n/*\nRun the macro\n*/\nexports.run = function(filter) {\n\tvar data = {tiddlers: {}};\n\tvar tiddlers = this.wiki.filterTiddlers(filter);\n\tfor(var t=0;t<tiddlers.length; t++) {\n\t\tvar tiddler = this.wiki.getTiddler(tiddlers[t]);\n\t\tif(tiddler) {\n\t\t\tvar fields = new Object();\n\t\t\tfor(var field in tiddler.fields) {\n\t\t\t\tfields[field] = tiddler.getFieldString(field);\n\t\t\t}\n\t\t\tdata[\"tiddlers\"][fields[\"title\"]] = fields;\n\t\t\tif (!(\"tags\" in data[\"tiddlers\"][fields[\"title\"]])) {\n\t\t\t   data[\"tiddlers\"][fields[\"title\"]][\"tags\"] = \"\";\n\t\t\t}\n\t\t\tdata[\"tiddlers\"][fields[\"title\"]][\"tags\"] += \" FromWikiAsAPlugin\";\n\t\t}\n\t}\n\treturn JSON.stringify(data,null,$tw.config.preferences.jsonSpaces);\n};\n\n})();\n",

            "modified": "20151107083546128",

            "module-type": "macro",

            "tags": "WikiAsAPlugin FromSubwiki",

            "title": "$:/plugins/mannfr/twaap/plugintiddlers",

            "type": "application/javascript"

        },

        "$:/plugins/mannfr/twaap/export": {

            "created": "20151106215643136",

            "text": "\\define renderContent()\n<$text text=<<plugintiddlers filter:\"\"\"$(exportFilter)$\"\"\">>/>\n\\end\nauthor: {{$:/plugins/mannfr/twaap/config##author}}\ndescription: {{$:/plugins/mannfr/twaap/config##description}}\nlist: {{$:/plugins/mannfr/twaap/config##list}}\nplugin-type: plugin\ntitle: {{$:/plugins/mannfr/twaap/config##title}}\ntype: application/json\nversion: {{$:/plugins/mannfr/twaap/config##version}}\n\"\"\"\n\n\"\"\"\n<<renderContent>>\n",

            "description": "~TwiddlyWiki as a Plugin (.tid)",

            "extension": ".tld",

            "modified": "20151107084633193",

            "tags": "$:/tags/Exporter WikiAsAPlugin FromSubwiki",

            "title": "$:/plugins/mannfr/twaap/export"

        }

    }

}

[Jeremy Ruston]

Hi Tobias

On 7 Nov 2015, at 08:36, Tobias Beer <beert...@gmail.com> wrote:

Currently, we are limited in leveraging this by a sophisticated plugin-mechanism that defies a simple "reuse tidbits" approach and forces a "publish a versioned bundle of codebits and supporting tids for distribution".

I’d like to understand the issues you see with the current plugin mechanism. Are you envisaging a specific alternative? 

There are currently two ways to “reuse tidbits”: a JSON file or a plugin. The JSON file is just about the simplest thing it could be: a nice simple plain text rendering of the source of a group of tiddlers, and is easy to work with in other tools. The plugin mechanism introduces just enough “sophistication” to satisfy their purpose: to be an *updatable* reusable tidbit.

Is it just that the support for building plugins in the browser is primitive?

Best wishes

Jeremy

[Christopher Mann]

Hi,

I've set up the PlugOut mechanism to my satisfaction.

How does one set up a private plugin repository?

Thanks,

Christopher

[Tobias Beer]

Hi Jeremy, 

Currently, we are limited in leveraging this by a sophisticated plugin-mechanism that defies a simple "reuse tidbits" approach and forces a "publish a versioned bundle of codebits and supporting tids for distribution".

I’d like to understand the issues you see with the current plugin mechanism. Are you envisaging a specific alternative? 

Thanks for asking. Not sure about the specifics, the tenets of improvements might be:

1. easy bundling of tiddlers
• come to think of it, including plugins
  
2. for reuse in a bundled manner
• meaning: as shadows (compare: inclusion on TiddlySpace)
  

The plugin mechanism does cater for (some of?) that scenario, only the means to use it for this purpose are possibly limited to selected individuals who know the how to's. To me, the goal would be indeed to simplify this "packaging" process and thus allow reusing tiddler packages in different context, as if plugins (or then actual plugins), and possibly even containing not only content but also structure, even functionality... in short: whatever ...could be my master template packaging all kinds of things, reused throughout my wikis. Could be a "my docs package". Could be a "my todo setup" containing the basic scaffolding for my to do list workflow... however, on a much more "simply create and use a basic package" level rather than a "figure out how to package and manage plugins" level, with versioning, naming conventions or whatever may be recommended for tried and true plugins, rather than "simple bundles".

There are currently two ways to “reuse tidbits”: a JSON file or a plugin. The JSON file is just about the simplest thing it could be: a nice simple plain text rendering of the source of a group of tiddlers, and is easy to work with in other tools. The plugin mechanism introduces just enough “sophistication” to satisfy their purpose: to be an *updatable* reusable tidbit.

So, yes, the way how plugins work once they exist is great. Just the way to create one is not as simple as it could be to allow for a more user centric packaging of whatever tidbits into bundles. In fact, I'd even shy away from using the name "plugin", as it comes with the connotation of being a developed thing, coded of sorts. Psychologically alone, simply packing up tiddlers into reusable bundles (being shadows in a target wiki) would sound much simpler than being the author of a plugin and all the presumed responsibility one might assume comes with such a position. It would make packaging a common task and process rather than a by default advanced, elevated one.

 

Is it just that the support for building plugins in the browser is primitive?

I guess so. By default, such a packer would create the most simplistic package conceivable, in terms of setup and required data. (Right now I don't even know the full requirements for plugins, tbh. (without researching) ...and then perhaps an "advanced options" panel that can be toggled so as to specify any other (plugin) parameters that may be needed / used / specified, perhaps with a help / info bubble that explains what a given metadata-field is for.

Pragmatically speaking: possibly a streamlined Tinka that...

• makes tiddler selection as easy as possible
• currently, selecting tiddlers is by individually ticking off checkboxes next to titles matching a manually entered filter
• only asks to specify the most basic details required for packaging, leaving out everything that truly is not
• in fact, could be just a title and nothing but
• avails the complete / advanced options in an expandable section

Best wishes,

— tb

[Christopher Mann]

Hi again,

Would you please be able to give me feedback on this approach?

https://github.com/chris2fr/tiddlywiki-as-plugin

It is about using the plugin mechanism to try to satisfy George Geek and perhaps Tobias Beer. It works as an export filter. 

Thanks,

Christopher

[Christopher Mann]

Hi,

Now that I have finished "AsPlugin" (I think "Export as Plugin" would have been a better name), I would like to set up some kind of "PlugOut" system.

https://github.com/chris2fr/tiddlywiki-as-plugin

PlugOut would be a repository, even on a local filesystem, that would act as a library for Plugins. I could export the current wiki as a plugin and load it into the PlugOut library. Thus all the other wikis could update themselves from the PlugOut library.

Pretty nifty, huh?

Christopher

P.S. If I wanted to have my plugin created dynamically in the current wiki, I would have to have one tiddler change the contents of another tiddler because plugin tiddlers are not calculated. C:

[Christopher Mann]

New name idea : ShadowWiki

[Jeremy Ruston]

Hi Christopher

Good stuff.

You may have seen it already, but there is a core function you can call in the browser to create a plugin:

http://tiddlywiki.com/dev/#How%20to%20create%20plugins%20in%20the%20browser

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/utils/pluginmaker.js

The reason that the core doesn’t have an “export as plugin” option is because there’s currently no mechanism for the user to specify the other parameters needed to create the plugin: the title of the plugin tiddler, and the version number. What are you currently using as the fields of the plugin tiddler? The upgrade mechanism relies on the version number being bumped on each revision.

In terms of dynamically updating installed plugins, there is of course already a mechanism to do that via the plugin library. The internals are a bit counter-intuitive because of the same origin limitations that browser’s impose; it’s not an option to just xmlhttprequest() to retrieve the new text of a plugin.

The plugin library is represented as an HTML file that TW loads in an iframe, and then communicates with using window.postMessage(). The HTML file is allowed to use xmlhttprequest() to retrieve plugins from the same domain from which it was loaded.

The easiest way to explore might be to first look at the plugin library HTML file:

http://tiddlywiki.com/library/v5.1.9/index.html

You can see the raw files here:

https://github.com/Jermolene/jermolene.github.io/blob/master/library/v5.1.9/index.html

The plugin library is built from this special edition:

https://github.com/Jermolene/TiddlyWiki5/blob/master/editions/pluginlibrary

Most of the logic is in this plugin:

https://github.com/Jermolene/TiddlyWiki5/tree/master/plugins/tiddlywiki/pluginlibrary

The TW code that interacts with the plugin library is here:

https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/browser-messaging.js

PlugOut would be a repository, even on a local filesystem, that would act as a library for Plugins.

The obstacle here is that Chrome doesn’t let files loaded on a file:// URI perform any xmlhttprequest() to other file:// URIs.

My warning would be that the entire approach to implementing the plugin library was shaped by the browser security restrictions. I’d recommend careful testing before you rely on a browser capability actually working in the right scenarios.

Good luck,

Best wishes

Jeremy.

-- 
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/4f80c990-0b2a-412f-9116-7bdd3c51a2cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christopher Mann]

Hi,

Many thanks for the pointers and the precise information about the plugin library generation and ideas around export as plugin.

What are you currently using as the fields of the plugin tiddler?

The data tiddler $:/plugins/chris2fr/asplugin/config is « unshadowed » with local configuration. 

The upgrade mechanism relies on the version number being bumped on each revision.

I versioning the wiki-plugins 0.0.<<now YYYY0MM0DD0hh0mm>>.

The plugin library is represented as an HTML file that TW loads in an iframe, and then communicates with using window.postMessage().

I am being really lazy here perhaps, but how do I construct recipes/library/tiddlers.json and "recipes/library/tiddlers/" + encodeURIComponent(title) + ".json »?

PlugOut would be a repository, even on a local filesystem, that would act as a library for Plugins. 

The obstacle here is that Chrome doesn’t let files loaded on a file:// URI perform any xmlhttprequest() to other file:// URIs.

Good to know. The file:// use is somewhat iffy anyway. 

My warning would be that the entire approach to implementing the plugin library was shaped by the browser security restrictions. I’d recommend careful testing before you rely on a browser capability actually working in the right scenarios.

Improvement ideas:

* Get the last part of ‘title’ from the URL (hence not needing any configuration)

* Have a front-end for the configuration instead of that data tiddler (and perhaps put the data tiddler directly in the Control Panel while we wait)

* Have a « push-to-library » function (will need a server)

* Use the internal plugin-maker, if I can

Good luck,

Thank you,

Christopher

[Eric Shulman]

On Monday, November 9, 2015 at 1:06:34 AM UTC-8, Jeremy Ruston wrote:

The obstacle here is that Chrome doesn’t let files loaded on a file:// URI perform any xmlhttprequest() to other file:// URIs.

Have you tried adding "--allow-file-access-from-files" to the command used to launch Chrome?

-e

[Jeremy Ruston]

Hi Tobias

OK, it sounds like your concerns are with the UI for making plugins, and perhaps with the name “plugins”. I was worried that you were seeing issues with the plugin architecture, since we can improve the UI but it’s tricky to change the architecture at this point.

For what it’s worth, I quite like the word “plugins”, closely followed by “bundle”. “Plugin” at least describes what one does with one of these things: they are designed to be plugged into wikis. The trouble with “bundle” is that we need a word that communicates the differences between a plugin (with it’s upgrade logic) and a bundle (without that logic). So right now I’d use “bundle” to describe a JSON file containing a bunch of tiddlers.

The community is doing a good job exploring UIs for making plugins, and I’m confident that we will evolve better approaches.

Right now I don't even know the full requirements for that, tbh. (without researching it)

Perhaps you could have a look at the current implementation? I think that your feedback and suggestions would be more valuable if you had that extra insight.

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c7ad0b42-400a-491b-986d-e96305e6ea6c%40googlegroups.com.

[Jeremy Ruston]

Hi Eric

Have you tried adding "--allow-file-access-from-files" to the command used to launch Chrome?

I know about the flag, and it’s certainly useful sometimes. But I couldn’t build the TW plugin library in a way that required every user to set that flag.

Best wishes

Jeremy.

-e

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7fd00122-e068-4262-ab15-fcbab13def25%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

OK, it sounds like your concerns are with the UI for making plugins, and perhaps with the name “plugins”. I was worried that you were seeing issues with the plugin architecture, since we can improve the UI but it’s tricky to change the architecture at this point.

Admittedly, and as anyone can possibly notice, I have yet to publish an actual plugin. So far, I have shied away from leveraging the mechanism for the purpose of distributing my codebits, mostly due to an incomplete node-dev-github-workflow to that end on my part... and all the additional steps involved in that.

Interestingly, except Erwan who does rely on that for indexing plugins, I don't think I've read any demands so far asking for it, or that this or that macro be wrapped up and shipped as a plugin. In the long term, I can see that the mechanism does perhaps provide better means for any (semi-automated) upgrade procedure via some future tb5 plugin library against which to check for updates.

~

Back to simple "bundles" and the context of "let's (allow to) create the simplest plugin possible": One should be able to not specify a version, not even a plugin-type, no readme and all that jazz and still have a "bundle of tiddlers" created / imported. None of these things are relevant for the most simple ad-hoc bundling.

Following your instructions here, I can see that the following won't do to create the simplest of "bundles":

title: bundle
type: application/json

{"tiddlers": {}}

with

title: foo
tags bar

baz

and then in the console:

$tw.utils.repackPlugin("bundle",["foo"]);

There are a number of issues with this:

1. I have to declare a valid plugin-type
• if I truly have to, and I'm not sure why I do, I'd rather want to use a plugin-type that indicates we're packaging a simple bundle, not a plugin
  
• in fact, any unrecognized plugin-type should possibly be interpreted as that
2. I do not want to fiddle with any versioning at the very beginning
• as it proves problematic for importing (the same version)
  
• so I need to repack my plugin
• but then the constituent tiddlers are gone
• so I need to find a way to start from a wiki with "unpacked" plugin components
• too many things to consider
3. repackPlugin should either
• a) never delete constituent tiddlers
  
• which means that you won't be able or even intend to use the "bundle" in the wiki where you created it (in the browser)
• since we still have the constituent tiddlers as real tiddlers, which is fine anyways
• in that sense, a user could be provided a button that creates a bundle on the fly whenever they want to grab it
• from whichever constituents they desire
• b) repack tiddlers that are already part of the bundle as shadows if they don't exist as real tiddlers
  
• as, obviously, those initially bundled tiddlers are now gone
• but then, how to remove one already packed?
• mhhh, maybe via some option to repackPlugin

For what it’s worth, I quite like the word “plugins”, closely followed by “bundle”. “Plugin” at least describes what one does with one of these things: they are designed to be plugged into wikis. The trouble with “bundle” is that we need a word that communicates the differences between a plugin (with it’s upgrade logic) and a bundle (without that logic). So right now I’d use “bundle” to describe a JSON file containing a bunch of tiddlers.

Exactly, a bundle would be a json file containing a bunch of tiddlers unpacked as shadows. 

There would possibly be a basic upgrade logic for "bundles" as well, namely: skip any version checks entirely. This could be achieved by setting an option flag for repackPlugin to not set any version, as we're not interested (yet) in doing so. A good alternative could be a YYYY-0MM-0DD-0hh-0mm-0ss version rather than the versioning scheme the name of which escapes me atm. But then, again, a set version comes with the troubles of not being able to import the same or lower version. And with a bundle I possibly don't want any of that. I just want to use that bundle as I just grabbed it.

The community is doing a good job exploring UIs for making plugins, and I’m confident that we will evolve better approaches.

Surely, I'm very interested in this and I'm sure that trying to (allow users to) start from the most basic "bundle" users may indeed eventually find themselves wanting to leverage more features / aspects of full-blown-plugins, e.g. versioning. But I'd be all fine to have this a gradual process, rather than one requiring literacy of all the intricacies of versioning, plugin-types, dependences, sources, readmes, howtos, docs and co etc...

Best wishes,

— tb

[Christopher Mann]

Hi All,

This is just to note that I have done a 0.0.8 release of AsPlugout.

Changes are:

* Name change from AsPlugin to AsPlugout

* Saves Wikis in $:/plugouts space instead of $:/plugins space

* Whole new configuration experience with front-end $:/plugins/chris2fr/asplugout/config

* Configuration now stored in in $:/config/chris2fr/asplugout/ tiddlers

I haven’t yet addressed the ideas around the Library, nor using the native features for plugin exporting.

I was able to use by exporting a wiki to a server, do changes, then downloading the .json tiddlers back to the original wiki.

Here is the repository:

https://github.com/chris2fr/tiddlywiki-as-plugin

The .tid file of the plugin can be obtained here:

 https://raw.githubusercontent.com/chris2fr/tiddlywiki-as-plugin/master/plugins/asplugout.tid

Christopher Mann

Le 10 nov. 2015 à 07:45, Tobias Beer <beert...@gmail.com> a écrit :

Hiu Jeremy,

 

OK, it sounds like your concerns are with the UI for making plugins, and perhaps with the name “plugins”. I was worried that you were seeing issues with the plugin architecture, since we can improve the UI but it’s tricky to change the architecture at this point.

Admittedly, and as anyone can possibly notice, I have yet to publish an actual plugin. So far, I have shied away from leveraging the mechanism for the purpose of distribution, mostly due to an unaccomplished development / node / guthub-workflow to that end on my part.

Interestingly, except Erwan who does rely on that for indexing plugins, I don't think I've read any demands so far that asked for this or that this or that macro be wrapped up and shipped as a plugin. In the long term, I can see that the mechanism does perhaps provide better means to provide for any (semi-automated) upgrade procedure via some future tb5 plugin library against which to check for updates.

~

Back to simple "bundles" and the context of "let's (allow to) create the simplest plugin possible": One should be able to not specify a version, maybe even plugin-type, and all that jazz and still have a "bundle of tiddlers" created / imported.

Following your instructions here, I can see that the following won't do to create the simplest of "bundles":

title: bundle
type: application/json

{"tiddlers": {}}

with

title: foo
tags bar

baz

and then in the console:

$tw.utils.repackPlugin("bundle",["foo"]);

There are a number of issues with this:

1. if I have to declare a plugin-type, I'd rather want to use a plugin-type that indicates we're packaging a simple bundle, not a plugin

• in fact, any unrecognized plugin-type should possibly be interpreted as that
1. I do not want to fiddle with any versioning at the very beginning
• as it proves problematic for importing (the same version)
  
• so I need to repack my plugin
• but then the constituent tiddlers are gone
• so I need to find a way to start from a wiki with "unpacked" plugin components
• too many things to consider
2. repackPlugin should either

• a) never delete constituent tiddlers
  

• which means that you won't be able or even intend to use the "bundle" in the wiki you created it (in the browser)

• since we still have the constituent tiddlers as real tiddlers, which is fine anyways
• in that sense, a user could be provided a button that creates a bundle on the fly whenever they want to grab it
• from whichever constituents they desire

• b) repack tiddlers that are already part of the bundle as shadows if they don't exist as real tiddlers
  
• as, obviously, those initially bundled tiddlers are now gone
• but then, how to remove one already packed?
• mhhh, maybe via some option to repackPlugin

For what it’s worth, I quite like the word “plugins”, closely followed by “bundle”. “Plugin” at least describes what one does with one of these things: they are designed to be plugged into wikis. The trouble with “bundle” is that we need a word that communicates the differences between a plugin (with it’s upgrade logic) and a bundle (without that logic). So right now I’d use “bundle” to describe a JSON file containing a bunch of tiddlers.

Exactly, a bundle would be a json file containing a bunch of tiddlers unpacked as shadows. 

There would possibly be a basic upgrade logic for "bundles" as well, namely: skip any version checks entirely. This could be achieved by setting an option flag for repackPlugin to not set any version, as we're not interested (yet) in doing so. Alternatively, a good alternative could be a YYYY-0MM-0DD-0hh-0mm-0ss version rather than the versioning scheme the name of which escapes me atm. But then, again, a set version comes with the troubles of not being able to import the same or lower version. And with a bundle I possibly don't want any of that. I just want to use that bundle as I just grabbed it.

The community is doing a good job exploring UIs for making plugins, and I’m confident that we will evolve better approaches.

Surely, I'm very interested in this and I'm sure that trying to (allow users to) start from the most basic "bundle" users may indeed eventually find themselves wanting to leverage more features / aspects of full-blown-plugins, e.g. versioning. But I'd be all fine to have this a gradual process, rather than one requiring literacy of all the intricacies of versioning, plugin-types, dependences, etc...

Best wishes,

— tb

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/HrL5owEOJKM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2a9099af-9291-48c4-a8c4-b6ffc1f41ba4%40googlegroups.com.

[Jeremy Ruston]

Hi Tobias

Interestingly, except Erwan who does rely on that for indexing plugins, I don't think I've read any demands so far that asked for this or that this or that macro be wrapped up and shipped as a plugin.

It’s pretty simple: it’s only worth using a plugin over a JSON bundle if you want (a) your tiddlers to appear as shadow tiddlers and (b) to be able to handle subsequent updates to the plugin. I think that the demand for plugins that can automatically upgrade is pretty strong.

In the long term, I can see that the mechanism does perhaps provide better means to provide for any (semi-automated) upgrade procedure via some future tb5 plugin library against which to check for updates.

It’s not really “future”; the plugin library and plugin upgrade procedure is already built into the core.

Back to simple "bundles" and the context of "let's (allow to) create the simplest plugin possible": One should be able to not specify a version, maybe even plugin-type, and all that jazz and still have a "bundle of tiddlers" created / imported.

But you already can! If you don’t want to have “all that jazz” then you can publish your tiddlers as a JSON bundle. But if you do want to have the ability to automatically upgrade then you need to use a plugin.

It really seems as though you are saying “plugins are too complicated, there needs to be a simpler alternative”, and yet there already is a simpler alternative available, in the shape of JSON bundles.

Following your instructions here, I can see that the following won't do to create the simplest of "bundles”:

I’m not sure what you’re saying here. Are you saying that the following steps don’t work? Or that they are not simple enough?

title: bundle
type: application/json

{"tiddlers": {}}

with

title: foo
tags bar

baz

and then in the console:

$tw.utils.repackPlugin("bundle",["foo"]);

There are a number of issues with this:

1. if I have to declare a plugin-type, I'd rather want to use a plugin-type that indicates we're packaging a simple bundle, not a plugin

• in fact, any unrecognized plugin-type should possibly be interpreted as that

Please don’t try to to unilaterally change the vocabulary that we have already established. These things are called “plugins” and not “bundles”. Changing the name is a big deal that will affect a lot of the code, and shouldn’t just be done unilaterally in a mailing list post; it’s incredibly confusing.

I think you’re saying that you’d like the “plugin-type” field to default to “plugin”. I think you’re just not seeing that there are a different types of plugin, and we need to distinguish them because they have different semantics; for example, only one language or theme can be switched in at once.

2. I do not want to fiddle with any versioning at the very beginning

You don’t have to fiddle with the version at the beginning, but you won’t be able to use the upgrade mechanism effectively until you do.

• as it proves problematic for importing (the same version)
  

I don’t think that there is a problem; an incoming plugin with the same version is treated as newer, and is imported.

• so I need to repack my plugin
• but then the constituent tiddlers are gone
• so I need to find a way to start from a wiki with "unpacked" plugin components
• too many things to consider

Again, it seems like you are confusing the current implementation of packing plugins in the browser (which was done in 30 minutes in response to a mailing list request) with the way that plugins are implemented.

3. repackPlugin should either

• a) never delete constituent tiddlers
  

• which means that you won't be able or even intend to use the "bundle" in the wiki you created it (in the browser)

• since we still have the constituent tiddlers as real tiddlers, which is fine anyways
• in that sense, a user could be provided a button that creates a bundle on the fly whenever they want to grab it
• from whichever constituents they desire

• b) repack tiddlers that are already part of the bundle as shadows if they don't exist as real tiddlers
  
• as, obviously, those initially bundled tiddlers are now gone
• but then, how to remove one already packed?
• mhhh, maybe via some option to repackPlugin

I’m sure the procedure can be improved.

For what it’s worth, I quite like the word “plugins”, closely followed by “bundle”. “Plugin” at least describes what one does with one of these things: they are designed to be plugged into wikis. The trouble with “bundle” is that we need a word that communicates the differences between a plugin (with it’s upgrade logic) and a bundle (without that logic). So right now I’d use “bundle” to describe a JSON file containing a bunch of tiddlers.

Exactly, a bundle would be a json file containing a bunch of tiddlers unpacked as shadows. 

But then you are talking about a plugin, not a bundle. If you want the shadow plugin then you need a plugin; that is what they are for. The whole point of them is to give us shadow tiddlers. So trying to find some other way of implementing shadow tiddlers just seems a bit strange.

There would possibly be a basic upgrade logic for "bundles" as well, namely: skip any version checks entirely. This could be achieved by setting an option flag for repackPlugin to not set any version, as we're not interested (yet) in doing so.

Again, it seems like you are trying to give JSON bundles the characteristics of plugins. It’s hard to see how we can do that without making them plugins.

If you import a JSON bundle with newer versions of the constituent tiddlers, then your existing ones will be overwritten. Isn’t that precisely the behaviour you’re asking for?

Alternatively, a good alternative could be a YYYY-0MM-0DD-0hh-0mm-0ss version rather than the versioning scheme the name of which escapes me atm. But then, again, a set version comes with the troubles of not being able to import the same or lower version. And with a bundle I possibly don't want any of that. I just want to use that bundle as I just grabbed it.

If you look at semver.org you’ll see that your proposal doesn’t in fact conflict; semver allows for version numbers like 1.0.201511050347

The community is doing a good job exploring UIs for making plugins, and I’m confident that we will evolve better approaches.

Surely, I'm very interested in this and I'm sure that trying to (allow users to) start from the most basic "bundle" users may indeed eventually find themselves wanting to leverage more features / aspects of full-blown-plugins, e.g. versioning. But I'd be all fine to have this a gradual process, rather than one requiring literacy of all the intricacies of versioning, plugin-types, dependences, etc…

I’m not sure what you mean by a “gradual” process? We’ve got JSON bundles, and we’ve got plugins; how could the transition be any more gradual?

Best wishes

Jeremy

Best wishes,

— tb

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2a9099af-9291-48c4-a8c4-b6ffc1f41ba4%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

It’s not really “future”; the plugin library and plugin upgrade procedure is already built into the core.

Of course, I was referring to me using all that to distribute my own codebits via some pipeline relying on the core plugin mechanism and then perhaps the library mechanism, e.g. as Andreas implemented it for distributing Tinka.

But you already can! If you don’t want to have “all that jazz” then you can publish your tiddlers as a JSON bundle. But if you do want to have the ability to automatically upgrade then you need to use a plugin. 

 

It really seems as though you are saying “plugins are too complicated, there needs to be a simpler alternative”, and yet there already is a simpler alternative available, in the shape of JSON bundles.

I believe you are referring to exporting, not sure. This, to me, is a different approach. Yes, it bundles up tiddlers into json and then unbundles them on import. That's not quite what I'm after with what I called bundles which — just as plugins — would work with shadows. Forgive my ignorance if that was already possible, as I wouldn't know how.

I’m not sure what you’re saying here. Are you saying that the following steps don’t work? Or that they are not simple enough?

I do get a json tiddler, but the tiddlers it defines don't appear to be created as shadows upon reload. 

Please don’t try to to unilaterally change the vocabulary that we have already established. These things are called “plugins” and not “bundles”. Changing the name is a big deal that will affect a lot of the code, and shouldn’t just be done unilaterally in a mailing list post; it’s incredibly confusing.

Not trying to change the vocabulary, but rather wanting to leverage the load-as-shadows approach for any simple "bundle", that's basically it.

I think you’re saying that you’d like the “plugin-type” field to default to “plugin”.

Actually, I'd like it to default to nothing / not present at all, meaning: a "bundle" or perhaps a plugin of type "bundle" if it must be.

I think you’re just not seeing that there are a different types of plugin, and we need to distinguish them because they have different semantics; for example, only one language or theme can be switched in at once.

I understand that. However, a simple bundle would not be tied with any such semantics, as it would be a losely defined, albeit kept together bundle of tiddlers that exist as shadows, combined in a plugin-like json tiddler from which they are created on startup, rather than unpacked upon import.

You don’t have to fiddle with the version at the beginning, but you won’t be able to use the upgrade mechanism effectively until you do.

As with any plain tiddler, a simple bundle would simply be overwritten, as it knows nothing of either versions or plugin-types and their purposes... it would be agnostic to any of that.

I don’t think that there is a problem; an incoming plugin with the same version is treated as newer, and is imported.

Again, a "bundle", the way I see it, should behave like a simple tiddler upon upgrading, the only difference being that its constituent tiddlers would be unpacked as shadows, as plugins do. 

Again, it seems like you are confusing the current implementation of packing plugins in the browser (which was done in 30 minutes in response to a mailing list request) with the way that plugins are implemented.

Possibly. Not exactly sure about the differences in detail. At the moment, in this thread I am mostly concerned with how plugins work and how, compared to that, a simple "bundle" mechanism could work that uses the same "create components as shadows on startup" approach and that's mostly it. If existing, this should work the same under node or a browser, independent of how that "bundle" initially was created, e.g. via repackPlugin or some other means, e.g. a js macro wrapper around the core functions that do packaging.

But then you are talking about a plugin, not a bundle. If you want the shadow plugin then you need a plugin; that is what they are for. The whole point of them is to give us shadow tiddlers. So trying to find some other way of implementing shadow tiddlers just seems a bit strange.

To me it's not, strange that is, and it's basically the core point the my above considerations. The mechanism of creating shadows is useful in general whereas plugins would be a more sophisticated form of that, as we are facing more sophisticated requirements as compared to the kind of simple "bundles" I described. However, the core tenet of such a bundle would precisely be the shadow mechanism, otherwise we'd be talking export / import which is an essential bit of functionality, albeit less powerful than a bundle of shadows.

Again, it seems like you are trying to give JSON bundles the characteristics of plugins. It’s hard to see how we can do that without making them plugins.

Let me ask it this way: Are there JSON bundles right now that are not plugins? If yes, then to create the kind of bundles I considered, we would possibly have to use a plugin-type: bundle, that would basically losen all other restrictions, e.g. versioning.

If you import a JSON bundle with newer versions of the constituent tiddlers, then your existing ones will be overwritten. Isn’t that precisely the behaviour you’re asking for?

In terms of overwriting, it is indeed. In terms of having shadow tiddlers, it is not.

If you look at semver.org you’ll see that your proposal doesn’t in fact conflict; semver allows for version numbers like 1.0.201511050347

Good idea. Will have to explore how that can be leveraged. I feel like someone recently mentioned using that already.

I’m not sure what you mean by a “gradual” process? We’ve got JSON bundles, and we’ve got plugins; how could the transition be any more gradual?

I think it's clear by now: the key is the shadow mechanism. I would want the basic ability to use it via "bundles" that are json tiddlers and possibly nothing but, e.g. no other field requirements. If that makes for bundles be "plugins", I'm all fine with calling them "plugins" ...of type "bundle".

Best wishes,

— tb

[Jeremy Ruston]

Hi Tobias

I think there’s a lot of confusion here. The core has two features:

* “plugins”, which require a type, and can optionally have a version. They contain shadow tiddlers that are switched in when the plugin is loaded

* “bundles”, as we’re referring to JSON files containing a bundle of tiddlers that can be exported or imported as a single unit

I think you’re asking for “bundles” to behave like plugins, but for them to somehow not become plugins in the process. That’s the crux of what I’m not understanding.

Is it just the requirement for a “plugin-type” field? You must see that an indicator other than “type:application/json” is needed; otherwise the system would attempt to load all data tiddlers as plugins.

You seem to think that there are vague, unexpected restrictions on how plugins are formed, but I don’t really understand what you’re getting at. A plugin is a JSON tiddler with the additional field “plugin-type" appropriate content and the shadows packed into the body. How much simpler could it be?

Best wishes

Jeremy.

On 10 Nov 2015, at 15:33, Tobias Beer <beert...@gmail.com> wrote:

Hi Jeremy,

 

It’s not really “future”; the plugin library and plugin upgrade procedure is already built into the core.

Of course, I was referring to me using all that to distribute my own codebits via some pipeline relying on the core plugin mechanism and then perhaps the library mechanism, e.g. as Andreas implemented it for distributing Tinka.

But you already can! If you don’t want to have “all that jazz” then you can publish your tiddlers as a JSON bundle. But if you do want to have the ability to automatically upgrade then you need to use a plugin. 

 

It really seems as though you are saying “plugins are too complicated, there needs to be a simpler alternative”, and yet there already is a simpler alternative available, in the shape of JSON bundles.

I believe you are referring to exporting, not sure. This, to me, is a different approach. Yes, it bundles up tiddlers into json and then unbundles them on import. That's not quite what I'm after with what I called bundles which — just as plugins — would work with shadows. Forgive my ignorance if that was already possible, as I wouldn't know how.

I’m not sure what you’re saying here. Are you saying that the following steps don’t work? Or that they are not simple enough?

I do get a json tiddler, but the tiddlers it defines don't appear to be created as shadows upon reload. 

Please don’t try to to unilaterally change the vocabulary that we have already established. These things are called “plugins” and not “bundles”. Changing the name is a big deal that will affect a lot of the code, and shouldn’t just be done unilaterally in a mailing list post; it’s incredibly confusing.

Not trying to change the vocabulary, but rather wanting to leverage the load-as-shadows approach for any simple "bundle", that's basically it.

I think you’re saying that you’d like the “plugin-type” field to default to “plugin”.

Actually, I'd like it to default to nothing / not present at all, meaning: a "bundle" or perhaps a plugin of type "bundle" if it must be.

I think you’re just not seeing that there are a different types of plugin, and we need to distinguish them because they have different semantics; for example, only one language or theme can be switched in at once.

I understand that. However, a simple bundle would not be tied with any such semantics, as it would be a losely defined, albeit kept together bundle of tiddlers that exist as shadows, combined in a plugin-like json tiddler from which they are created on startup, rather than unpacked upon import.

You don’t have to fiddle with the version at the beginning, but you won’t be able to use the upgrade mechanism effectively until you do.

As with any plain tiddler, a simple bundle would simply be overwritten, as it knows nothing of either versions or plugin-types and their purposes... it would be agnostic to any of that.

I don’t think that there is a problem; an incoming plugin with the same version is treated as newer, and is imported.

Again, a "bundle", the way I see it, should behave like a simple tiddler upon upgrading, the only difference being that its constituent tiddlers would be unpacked as shadows, as plugins do. 

Again, it seems like you are confusing the current implementation of packing plugins in the browser (which was done in 30 minutes in response to a mailing list request) with the way that plugins are implemented.

Possibly. Not exactly sure about the differences in detail. At the moment, in this thread I am mostly concerned with how plugins work and how, compared to that, a simple "bundle" mechanism could work that uses the same "create components as shadows on startup" approach and that's mostly it. If existing, this should work the same under node or a browser, independent of how that "bundle" initially was created, e.g. via repackPlugin or some other means, e.g. a js macro wrapper around the core functions that do packaging.

But then you are talking about a plugin, not a bundle. If you want the shadow plugin then you need a plugin; that is what they are for. The whole point of them is to give us shadow tiddlers. So trying to find some other way of implementing shadow tiddlers just seems a bit strange.

To me it's not, strange that is, and it's basically the core point the my above considerations. The mechanism of creating shadows is useful in general whereas plugins would be a more sophisticated form of that, as we are facing more sophisticated requirements as compared to the kind of simple "bundles" I described. However, the core tenet of such a bundle would precisely be the shadow mechanism, otherwise we'd be talking export / import which is an essential bit of functionality, albeit less powerful than a bundles of shadows.

Again, it seems like you are trying to give JSON bundles the characteristics of plugins. It’s hard to see how we can do that without making them plugins.

Let me ask it this way: Are there JSON bundles right now that are not plugins? If yes, then to create the kind of bundles I considered, we would possibly have to use a plugin-type: bundle, that would basically losen all other restrictions, e.g. versioning.

If you import a JSON bundle with newer versions of the constituent tiddlers, then your existing ones will be overwritten. Isn’t that precisely the behaviour you’re asking for?

In terms of overwriting, it is indeed. In terms of having shadow tiddlers, it is not.

If you look at semver.org you’ll see that your proposal doesn’t in fact conflict; semver allows for version numbers like 1.0.201511050347

Good idea. Will have to explore how that can be leveraged. I feel like someone recently mentioned using that already.

I’m not sure what you mean by a “gradual” process? We’ve got JSON bundles, and we’ve got plugins; how could the transition be any more gradual?

I think it's clear by now: the key is the shadow mechanism. I would want the basic ability to use it via "bundles" that are json tiddlers and possibly nothing but, e.g. no other field requirements. If that makes for bundles be "plugins", I'm all fine with calling them "plugins" ...of type "bundle".

Best wishes,

— tb

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3a72c359-6b34-4b4b-93e6-cb50bd109460%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

I think there’s a lot of confusion here. The core has two features:

* “plugins”, which require a type, and can optionally have a version. They contain shadow tiddlers that are switched in when the plugin is loaded

* “bundles”, as we’re referring to JSON files containing a bundle of tiddlers that can be exported or imported as a single unit

Possibly, there is some mixing up in terms of ...terms. So far, I have not recognized the term "bundle" as part of the core lingo... which is more or less confirmed by searching for it on TiddlyWiki.com. Of course, I knew plugins that are actually introduced as "bundles of tiddlers" and of JSON tiddlers introduced as "data tiddlers".

Whatever I was referring to as "bundle" indeed is located in the middle, feature- / constraint-wise.

 

I think you’re asking for “bundles” to behave like plugins, but for them to somehow not become plugins in the process. That’s the crux of what I’m not understanding. 

Is it just the requirement for a “plugin-type” field? You must see that an indicator other than “type:application/json” is needed; otherwise the system would attempt to load all data tiddlers as plugins.

I can see where the confusion was coming from. Certainly, the kind of "bundles" I was referring to were by design of type:application/json, at least in terms of format, which means that they would need to be more than just plain json data tiddlers in order to work the shadow magic, as we don't unpack those the shadow tiddler way.

Introducing another type of tiddler may be a shortcut to actually reducing confusion and to distinguish whatever we would call such a "bundle" from (other types of) plugins. The kind of "simple bundle" I had in mind being defined as:

1. having the structure of plain json data tiddlers
2. implementing the shadow mechanism of plugins
   
3. may contain other plugins

So, unlike "plugins", "themes", or "languages" they would have no special treatment, except, any plugins contained in such a "bundle" would be loaded as plugins, in other words, a plugin in a plugin. Whether such a construct would be called "bundle" is not so much of importance, compared to the desire for that to exist. Clearly, plugins are more than just that / require more than the above to get going (or are constrained by not providing 3., perhaps).

But yes, like current plugins, one may want a central spot to look at "bundles". So, it would be wise to have them be of a plugin-type:bundle (or any other name) and then show them in a corresponding tab under ControlPanel > Plugins > Bundles.

You seem to think that there are vague, unexpected restrictions on how plugins are formed, but I don’t really understand what you’re getting at.

Not at all. My suggestions were in no way intended as criticism. Instead, I was wondering how to arrive at the above model+behavior.

A plugin is a JSON tiddler with the additional field “plugin-type" appropriate content and the shadows packed into the body. How much simpler could it be?

I would be all fine to introduce plugin-type:bundle, which would loosen up on any requirements that go beyond 1. and 2. above and treat such a bundle as if a regular tiddler (especially with respect to import), except for the shadow magic.

Such "bundles" could serve a wide range of purposes:

• including an entire wiki in another wiki, as the OP
  
• apps / app scaffoldings / workflows / components
  
• complex themes
  
• plugin bundles
  
• user preferences
  
• content bundles, e.g. "help"
  
• etc...
  

Best wishes,

— tb

[Christopher Mann]

Hey guys,

Me again.  I have been having way too much fun with this for my own good.

It sounds like « plugout » introduces a new term and would be too confusing. So I will go back to plugin soon.

I have a demo site up here:

http://tiddlywiki.howwownow.com/

Most importantly, the draggle plugin is available here:

http://tiddlywiki.howwownow.com/#%24%3A%2Fplugins%2Fchris2fr%2Fasplugout

The Tiddly site also serves as a demo site. You can [Export All] -> [TiddlyWiki as Plugout (.tid)] and import that anywhere as a plugin.  It is non-intrusive, mostly.

Feel free to play with the « Plugout » SideBar as well.

Perhaps a better name would be TiddlyShadow. I like thinking about names.

Christopher Mann

Le 10 nov. 2015 à 18:02, Tobias Beer <beert...@gmail.com> a écrit :

Hi Jeremy,

 

I think there’s a lot of confusion here. The core has two features:

* “plugins”, which require a type, and can optionally have a version. They contain shadow tiddlers that are switched in when the plugin is loaded

* “bundles”, as we’re referring to JSON files containing a bundle of tiddlers that can be exported or imported as a single unit

Possibly, there is some mixing up in terms of ...terms. So far, I have not recognized the term "bundle" as part of the core lingo... which is more or less confirmed by searching for it on TiddlyWiki.com. Of course, I knew plugins that are actually introduced as "bundles of tiddlers" and of JSON tiddlers introduced as data tiddlers.

Whatever I was referring to as "bundle" indeed is located in the middle, feature- / constraint-wise.

 

I think you’re asking for “bundles” to behave like plugins, but for them to somehow not become plugins in the process. That’s the crux of what I’m not understanding. 

Is it just the requirement for a “plugin-type” field? You must see that an indicator other than “type:application/json” is needed; otherwise the system would attempt to load all data tiddlers as plugins.

I can see where the confusion was coming from. Certainly, the kind of "bundles" I was referring to were by design of type:application/json, at least in terms of format, which means that they would need to be more than just plain json data tiddlers in order to work the shadow magic, as we don't unpack those the shadow tiddler way.

Introducing another type of tiddler may be a shortcut to actually reducing confusion and to separate whatever such a "bundle" could be called from plugins. The kind of "simple bundle" I had in mind being defined as:

1. having the structure of plain json data tiddlers
2. implementing the shadow mechanism of plugins
   

...and that's it. So, unlike "plugins", "themes", or "languages" they would have no special treatment, except, any plugins contained in such a "bundle" would be loaded as plugins, in other words, a plugin in a plugin. Whether such a construct would be called "bundle" is not so much of importance as the desire for that to exist. Clearly, plugins are more than just that / require more than the above to get going.

But yes, like current plugins, one may want a central spot to look at "bundles". So, it would be wise to have them be of a plugin-type:bundle (or any other name) and then show them in a corresponding tab under ControlPanel > Plugins > Bundles.

You seem to think that there are vague, unexpected restrictions on how plugins are formed, but I don’t really understand what you’re getting at.

Not at all. My suggestions were in no way intended as criticism. Instead, I was wondering how to arrive at the above model+behavior.

A plugin is a JSON tiddler with the additional field “plugin-type" appropriate content and the shadows packed into the body. How much simpler could it be?

I would be all fine to introduce plugin-type:bundle, which would loosen up on any requirements that go beyond 1. and 2. above and treat such a bundle as if a regular tiddler, especially upon import, except for the shadow magic.

Bundles could serve a wide range of purposes:

* app setups
* complex themes

* user preferences
* content bundles, e.g. "help"

* etc...

Best wishes,

— tb

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/HrL5owEOJKM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/533fcff5-b41b-4801-84d4-ac055362a5a4%40googlegroups.com.

[Jeremy Ruston]

Hi Tobias

Thanks for your patience with the discussion, it’s useful and interesting!

Possibly, there is some mixing up in terms of ...terms. So far, I have not recognized the term "bundle" as part of the core lingo... which is more or less confirmed by searching for it on TiddlyWiki.com. Of course, I knew plugins that are actually introduced as "bundles of tiddlers" and of JSON tiddlers introduced as data tiddlers.

It was probably a mistake to continue to use the word “bundle” in this thread. For clarity, I was using the term to describe a JSON file containing a number of tiddlers.

I can see where the confusion was coming from. Certainly, the kind of "bundles" I was referring to were by design of type:application/json, at least in terms of format, which means that they would need to be more than just plain json data tiddlers in order to work the shadow magic, as we don't unpack those the shadow tiddler way.

OK, so what’s wrong with using a field like “plugin-type” to indicate that the special behaviour of unpacking shadow tiddlers should take place?

Introducing another type of tiddler may be a shortcut to actually reducing confusion and to separate whatever such a "bundle" could be called from plugins. The kind of "simple bundle" I had in mind being defined as:

1. having the structure of plain json data tiddlers
2. implementing the shadow mechanism of plugins
   

...and that's it. So, unlike "plugins", "themes", or "languages" they would have no special treatment, except, any plugins contained in such a "bundle" would be loaded as plugins, in other words, a plugin in a plugin. Whether such a construct would be called "bundle" is not so much of importance as the desire for that to exist. Clearly, plugins are more than just that / require more than the above to get going.

What do you mean by “special treatment”? Plugins (where `plugin-type` is “plugin”) have no special behaviour in the wiki store beyond the unpacking of shadow tiddlers. Features like the plugin listing in the control panel aren’t intrinsic to the plugin mechanism; they’re just tiddlers in the control panel.

What special treatment do you think plugins are subject to that you’d like to avoid?

But yes, like current plugins, one may want a central spot to look at "bundles". So, it would be wise to have them be of a plugin-type:bundle (or any other name) and then show them in a corresponding tab under ControlPanel > Plugins > Bundles.

Now that you’re bring even more of the behaviour of plugins to your “bundles” I’m really failing to see the difference between a bundle and a plugin. Surely you are just re-inventing plugins?

You seem to think that there are vague, unexpected restrictions on how plugins are formed, but I don’t really understand what you’re getting at.

Not at all. My suggestions were in no way intended as criticism. Instead, I was wondering how to arrive at the above model+behavior.

But you are saying that the plugin mechanism isn’t suitable for the purpose you have in mind, and yet as a replacement you are suggesting adding all the features of plugins to JSON tiddlers.

A plugin is a JSON tiddler with the additional field “plugin-type" appropriate content and the shadows packed into the body. How much simpler could it be?

I would be all fine to introduce plugin-type:bundle, which would loosen up on any requirements that go beyond 1. and 2. above and treat such a bundle as if a regular tiddler, especially upon import, except for the shadow magic.

Bundles could serve a wide range of purposes:

* app setups
* complex themes

* user preferences
* content bundles, e.g. "help"

* etc…

But that is exactly what plugins are for! Again and again you are saying that something else is needed and yet you are just describing the existing behaviour of plugins.

Best wishes

Jeremy.

Best wishes,

— tb

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/533fcff5-b41b-4801-84d4-ac055362a5a4%40googlegroups.com.

[Tobias Beer]

Hi Christopher,

 

It sounds like « plugout » introduces a new term and would be too confusing. So I will go back to plugin soon.

I tend to agree. 

I have a demo site up here:

http://tiddlywiki.howwownow.com/

When I export your "wiki", for example the SiteTitle does not get packaged. Is that by design and if so, what does precisely get exported / "plugged out"?

Best wishes,

— tb

[Christopher Mann]

Hey, 

Thanks for looking.

http://tiddlywiki.howwownow.com/

When I export your "wiki", for example the SiteTitle does not get packaged. Is that by design and if so, what does precisely get exported / "plugged out"?

The point is that the content of the plugged-out wiki does not crush the content of the plugged in wiki.

The SiteTitle actually is the default for the plugin Description.

I added 

http://tiddlywiki.howwownow.com/pluggedin.html 

(with a website inside as plugged in)

to show how it works, and

http://tiddlywiki.howwownow.com/empty.html

and 

http://tiddlywiki.howwownow.com/pluggedout.html

(with the AsPlugout plugin)

to play with.

Christopher Mann

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/HrL5owEOJKM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1072ce1d-c938-4f01-a11a-33aaeecad0cf%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

OK, so what’s wrong with using a field like “plugin-type” to indicate that the special behaviour of unpacking shadow tiddlers should take place?

Nothing at all. Not sure, perhaps I made such a suggestion by mistake / omission. I think by now we have established that the kind of bundles I described are (/ or at least can be) indeed plugins, of a new plugin-type.

What do you mean by “special treatment”? Plugins (where `plugin-type` is “plugin”) have no special behaviour in the wiki store beyond the unpacking of shadow tiddlers. Features like the plugin listing in the control panel aren’t intrinsic to the plugin mechanism; they’re just tiddlers in the control panel. 

 

What special treatment do you think plugins are subject to that you’d like to avoid?

Most prominently, version handling, especially upon import. Other than that (possible / optional) expectations / conventions for the control-panel to not expect (m)any details, etc..

Now that you’re bring even more of the behaviour of plugins to your “bundles” I’m really failing to see the difference between a bundle and a plugin. Surely you are just re-inventing plugins?

These are the things I'd want from a "bundle":

1. no versioning requirements
• so, no version check on import
  
• this is the most important simplification over current(ly avalable) plugin( type)s
2. be able to bundle any tiddlers, including other plugins
• this does not seem to be possible at the moment
• a shadow-plugin won't create any shadows it contains recursively when created as a shadow
3. no deletion of constituent plugin-tiddlers when performing repackPlugin
   
• the source wiki should stay functional as is
• e.g. when bundling up an entire wiki or content, I don't want to look at an empty wiki after clicking that button

I would not call that reinventing, but rather conventions for a new plugin-type that both has simplification (versioning) and additional capabilities (plugin-bundling).

But you are saying that the plugin mechanism isn’t suitable for the purpose you have in mind, and yet as a replacement you are suggesting adding all the features of plugins to JSON tiddlers.

I hope it is clear now that the above mentioned requirements are not met, as of today. At least, there appears to be no existing plugin-type workflow available to cater for either.

A plugin is a JSON tiddler with the additional field “plugin-type" appropriate content and the shadows packed into the body. How much simpler could it be?

But that is exactly what plugins are for! Again and again you are saying that something else is needed and yet you are just describing the existing behaviour of plugins.

Currently, we cannot create the kind of bundle (as a plugin) with the requirements listed above, can we?

Best wishes,

— tb

[Jeremy Ruston]

Hi Tobias

Nothing at all. Not sure, perhaps I made such a suggestion by mistake / omission. I think by now we have established that the kind of bundles I described are (/ or at least can be) indeed plugins, of a new type.

I’m afraid we’ve not established that at all! As far as I can see, you’re reinventing the existing plugin mechanism.

Most prominently, version handling, especially upon import.

But there is no special version handling on import for plugins that don’t carry a version number. So if for some reason you don’t like the version checking, just don’t include a version number field.

Other than that (possible / optional) expectations / conventions for the control-panel to show details, etc..

Are you suggesting that there is a requirement for a type of plugin that doesn’t show up in control panel?

Now that you’re bring even more of the behaviour of plugins to your “bundles” I’m really failing to see the difference between a bundle and a plugin. Surely you are just re-inventing plugins?

These are the things I'd want from a "bundle":

1. no versioning requirements

• so, no version check on import
  

• this is the most important simplification over current plugins

See above. There is no “versioning requirement” for plugins. Just that plugins that have a version number can participate in automatic upgrading (clearly some kind of version number is needed for upgrade tracking).

2. be able to bundle any tiddlers, including other plugins
• this does not seem to be possible at the moment
• a shadow-plugin won't create any shadows it contains recursively

That’s the first time you’ve mentioned a requirement for recursive plugins. Why is it important? As it happens, the plugin mechanism could be extended to do it, but I’d really like to understand why - it seems like a horrendously inefficient way of packaging most things.

3. no deletion of constituent plugin-tiddler when performing repackPlugin
   

• the source wiki should stay functional as is

But that’s barely anything to do with the plugin mechanism! You’re just talking about a very specific improvement/alteration to the repackplugin function.

I would not call that reinventing, but rather conventions for a new plugin-type that both has simplification (versioning) and additional capabilities (plugin-bundling).

I’m afraid you still haven’t made a comprehensible case for why a new type is needed.

But you are saying that the plugin mechanism isn’t suitable for the purpose you have in mind, and yet as a replacement you are suggesting adding all the features of plugins to JSON tiddlers.

I hope it is clear now that the above mentioned requirements are not met, as of today. At least, there appears to be no existing plugin-type workflow available to cater for either.

But they are! And have been from the beginning.

A plugin is a JSON tiddler with the additional field “plugin-type" appropriate content and the shadows packed into the body. How much simpler could it be?

But that is exactly what plugins are for! Again and again you are saying that something else is needed and yet you are just describing the existing behaviour of plugins.

Currently, we cannot create the kind of bundle (as a plugin) with the requirements listed above, can we?

I’m sorry, I’ve lost track of what you mean by “above”!

Best wishes

Jeremy

Best wishes,

— tb

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1a6e26f6-0f2a-41de-be30-a364bdfb0de7%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

But there is no special version handling on import for plugins that don’t carry a version number. So if for some reason you don’t like the version checking, just don’t include a version number field.

I'm sorry, I should have tested that.

Are you suggesting that there is a requirement for a type of plugin that doesn’t show up in control panel?

I guess, I'm not. It's possibly more conventions than requirements.

That’s the first time you’ve mentioned a requirement for recursive plugins. Why is it important? As it happens, the plugin mechanism could be extended to do it, but I’d really like to understand why - it seems like a horrendously inefficient way of packaging most things.

Sorry, I keep on editing my already long posts for clarification and then forget that you possibly only receive the original post via email. Presumably that's not a good practice. Anyhow, it is important whenever you want to bundle up literally anything, including plugins, as for the use-cases mentioned above:

• including an entire wiki in another wiki, as the OP (containing plugins)
  
• apps / app scaffoldings / workflows / components (containing plugins)
  
• complex themes (containing plugins)
  
• plugin bundles
  
• user preferences (in terms of plugin setups, thus plugin + config / mods)
  
• content bundles, e.g. "help" (that come with plugins)
  
• etc...

But that’s barely anything to do with the plugin mechanism! You’re just talking about a very specific improvement/alteration to the repackplugin function.

I tried to establish what it takes for using the plugin mechanism to create and use the kind of bundles described.

I hope it is clear now that the above mentioned requirements are not met, as of today. At least, there appears to be no existing plugin-type workflow available to cater for either. 

 

But they are! And have been from the beginning.

Correct me if I'm wrong, but we cannot bundle plugins in plugins. We cannot just bundle up tiddlers (in terms of leveraging the shadow tiddler mechanism) without them being called plugins (of type plugin). And, sorry, I did not know that by (whatever means of ) removing any created version field we can actually deactivate the version check mechanism.

I’m sorry, I’ve lost track of what you mean by “above”!

Allow me to repeat the requirements for the kinds of bundle's I like to see:

1. no versioning requirements
• turns out we already can, by removing any created version number
• ideally we could instruct repackPlugin not to set a version

1. be able to bundle any tiddlers, including other plugins

• this is mostly what's missing and, to me, warrants a new plugin-type

1. no deletion of constituent plugin-tiddlers when performing repackPlugin
   

• you appear to put that into a different bucket, even though it's a crucial part to the bundling process
• ideally, I'd want an option that allows me to instruct this method to not do that
1. to have "bundles", or whatever we call them, show up in the plugin ui but not under the "Plugins" tab
• since they are plugins by nature but should not be of plugin-type:plugin which should be reserved, imho, for well scoped single-purpose plugins, not arbitrary, even ad-hoc bundles that may even contain third party child-plugins

All of that eventually streamlined into the most simple ui for bundle creation, optionally extended with other, existing plugin-tiddler fields.

Best wishes,

— tb