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 <[email protected]> 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 <http://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 [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/tiddlywiki > <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 > > <https://groups.google.com/d/msgid/tiddlywiki/3a72c359-6b34-4b4b-93e6-cb50bd109460%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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/CC87B158-D6F7-41A9-A675-E278BA908621%40gmail.com. For more options, visit https://groups.google.com/d/optout.
