Hi Matabele, > Could Tobias please document the process of setting up a plugin library > like his? >
In the context of this thread, I think it would do a lot of good for all of us if we started to give the */dev* wiki about the same attention (if not a little more, for the time being) as the core documentation at *tiddlywiki.com*. Yes, I can write a handful of instructions, but possibly they all should eventually be on *tiddlywiki.com/dev* and not where ever I would quickly publish things. On this score, in order to use Tobias's library, I must first install a > plugin. Therefore, why not include plugin library plugins into the tw5 > plugin library as a 'hook' into 3rd party plugin libraries? > That is not exactly true. You simply need to import a tiddler that is NOT a plugin. All it does is to define a path to the library and some field describing that plugin resource. There can sure be a list of trusted plugin sources that actually come shipped with the core... where user's can feel confident that they're not going to install entirely experimental features, but possibly / hopefully the more stable ones. Also, the entire process of handling the plugin library needs a bit more *finishing* when it comes to: - catering for different plugin libraries - updating installed plugins - opening a plugin library listing ...as well as closing it Perhaps it would be more convenient for some plugin authors to submit their > plugins to a 3rd party plugin library than to the core? > All that really boils down to what works best. In act, you are totally right that there could be a "public" plugin library where all authors may want to push their plugins to be listed... one that is not necessarily part of the tiddlywiki.com repo. For the moment, I would think the approach of having: 1. either the core plugin library as a source for plugins 2. a given author's plugin library as a source for that ...is good enough as it somewhat makes the task of curating all of that one that is well defined in terms of responsibilities: For 1. it would be Jeremy to take the lead ad for 2. a given author. So, yes, there could be: 3. a "community plugin library" where someone would take it upon themselves to: - review any contributions, possibly also in terms of code - actively ask authors for contributions to that listing - manage the whole thing as a repository, possibly published on GitHub All that is not "far out there" but I imagine it takes a considerable amount of work to actually do... and some(one) willing to pull through the whole process and keep it up... because nothing is possibly as useless as a "community resource" that eventually dries out for there not really being a community to actually maintain it. In summary: the core plugin library should contain mostly plugin library > plugins as hooks to 3rd party plugin libraries rather than the plugins > themselves -- then, rather than submitting my contribution to the core > plugin library, an author can submit to a 3rd party plugin library (or > maintain their own 3rd party plugin library.) > I'd very much advocate this model. So, the task would be to develop a given level of confidence / trust into which of these resources are officially listed / shipped with the core (in terms of "listings"). Quite possibly, the actual plugin libraries themselves could be (selectively) fetched via some form of TWederation: - "Please give me a list of all plugin libraries, their descriptions and their plugin lists / descriptions ...so I can choose which of those I'd want to include in my wiki to later on pull plugins, even content from." This could also help with the TW federation infrastructure: a 3rd party > plugin library could be used as a intermediary for communication. In this > respect, it might be advantageous to produce an optimised, uglified and > stripped down version of the core specifically for the purpose. As it's > currently necessary to download the entire wiki to extract a single post or > comment -- the version opened in the iframe needs to be as small as > possible (all unnecessary functionality removed.) > There is definitely room for making servers cough less when shipping TiddlyWikis... I imagine it's a matter of working out the details to that workflow and actually doing it... knowing that this eventually will not be a good environment to debug issues in. ;-) Best wishes, Tobias. -- 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 https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/89382493-8db2-4aef-9628-2d0f4dec1653%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
