--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/2a76bfeb-b709-46a9-9797-ab4acb82c9a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
So, as mentioned in the OP I'm pretty leery of the "pre-boot" approach here. The modloader process uses quite a lot of $:/boot library functionality to identify and inspect shadow tiddlers as part of the patching process, and to generate the output plugin.
I also worry that working on the pre-boot DOM would create incompatibilities with certain TiddlyWiki environments (but I don't understand this low level stuff very well).
The current modloader can manipulate almost everything in the wiki except for startup modules and the modules they require, hence the request.
In most cases, bootloader modules (including modloader) are going to want to generate any output to $:/temp or similar, where they won't create persistent changes in the wiki.
--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/98a6ce14-9ba5-470d-b396-365f08ddd806%40googlegroups.com.
In most cases, bootloader modules (including modloader) are going to want to generate any output to $:/temp or similar, where they won't create persistent changes in the wiki.
Yes, but your proposed solution is just an escalation in an ongoing arms race to be the first module to run.
We’ve got to the point where the changes you are proposing to the core are quite deep, and have lots of implications for the rest of the core. It’s going to mean a lot of work on verification and testing from me, even if somebody else writes the code. I don’t think that burden is justified at present.
At this point, I don’t see any problem with your plugin duplicating a few hundred lines of boot.js.
This is almost, but not quite, the issue. My modloader is the first module to have any method called on it. However, TiddlyWiki currently loads (via $tw.module.execute) a very large number of modules prior to making any method calls. There is no control over the ordering of these executions, and they are subsequently impossible to change at boot-time without overwriting the core.
As I mentioned before, I think there's potentially a meaningful difference between startup modules and "bootloader" behaviors. Loading content and code into the tiddler store, versus setting up APIs, DOMs and run-time functionality. It's much more likely that a loader module would want to affect startup behavior than another loader module.
Anyway, the modloader doesn't need this functionality, strictly speaking. It just extends its capabilities a bit, so that the whole core can be patched by installed plugins. The modloader currently issues a warning when trying (and failing) to apply a patch of this nature so it shouldn't catch developers by surprise.
The design intent of the modloader is to maintain compatibility with future versions of TiddlyWiki. Duplicating bootloader behavior (which is subject to change) would detrimental enough to that goal that I'd rather stick with the current constraints.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/cf2e1886-225d-49a0-9232-c646ee5352f7%40googlegroups.com.
Bootloader modules feel a bit like an admission of defeat with respect to the startup module mechanism.
Aren’t (the executions before startup) just the cascade of modules requiring one another?
It might be a useful exercise to try to write the documentation for bootloader modules, and see whether one can explain the difference clearly without referencing the particular use case that has prompted this discussion.
The other problem is that my plugin's requirement — "minimize the number of modules executing before me" — is at odds with the dependency-oriented nature of startup modules. Modloader doesn't depend on any functionality other than what's provided by the bootloader.
Aren’t (the executions before startup) just the cascade of modules requiring one another?Yes. The requirement for my plugin is "run before most modules execute". There's no best practice for startup modules to discourage them from loading modules at execution time, and I'm not sure there should be(?), hence the conundrum.You'll notice my modloader plugin eclipses startup.js to move its require() call into its startup() method. If I don't do this, it's impossible to modify a large portion of the core (including all widgets). Unfortunately, this eclipsing is exactly the kind of thing the modloader is designed to avoid.
It might be a useful exercise to try to write the documentation for bootloader modules, and see whether one can explain the difference clearly without referencing the particular use case that has prompted this discussion."bootloader modules run during the boot process, allowing them to add, remove and modify tiddlers in the store prior to the wiki's startup process. This is useful for injecting plugins, code and content that TiddlyWiki isn't capable of refreshing at runtime. Injected content may be dynamically generated or loaded from an external source. These modules are encouraged to minimize their dependency upon other modules in the wiki and to avoid any dependency on the TiddlyWiki core.
bootloader modules may safely revise any content in the tiddler store with the exception of other bootloader modules and their dependencies.”
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/9a8c3a1b-e53c-42b1-9cde-c3a4bbcc7759%40googlegroups.com.
* The proposed modifications don’t have any anticipated benefit beyond the usage by the modloader plugin