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 [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/3a72c359-6b34-4b4b-93e6-cb50bd109460%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
