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:
- easy bundling of tiddlers
- for reuse in a bundled manner (compare: inclusion on TiddlySpace)
The plugin mechanism does cater for 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, a plugin packer would create the most simplistic
"plugin" conceivable, in terms of setup and required data. (Right now I
don't even know the full requirements for that, tbh. (without researching
it) ...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
--
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 [email protected].
To post to this group, send email to [email protected].
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.
For more options, visit https://groups.google.com/d/optout.
