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 <http://tiddlywiki.com/#PluginMechanism>" and of JSON <http://tiddlywiki.com/#JSONTiddlers> tiddlers introduced as data tiddlers <http://tiddlywiki.com/#JSONTiddlers>. 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 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/533fcff5-b41b-4801-84d4-ac055362a5a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
