Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hey, Jeremy — With what you've told me about the preboot approach on the call, it's starting to sound a bit better for modloader's needs. Learning that the serialization DOM format is fixed across all TW5 platforms helps me to visualize a solution. I'm wondering if this pre-boot approach will

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hi Evan > 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. “Minimize t

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hey, Jeremy — Bootloader modules feel a bit like an admission of defeat with respect to > the startup module mechanism. > Potentially this functionality could be an extension of the startup mechanism. Trouble is, in order to load and execute them one-by-one you'd need to be able to prioritize

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hi Evan Thanks, I’ll give your arguments more thought, and hope you can join the hangout tomorrow to discuss further. > 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)

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hey, Jeremy — > Yes, but your proposed solution is just an escalation in an ongoing arms > race to be the first module to run. 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.modul

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hi Evan 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 justif

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hey, Jeremy — 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 shad

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Here’s the .tid of the $:/PatchCore.js tiddler, too.Best wishesJeremy -- 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 tiddlywikidev+unsubscr...@googlegroups.com

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hi Evan I worked up the technique I mentioned, and it may be suitable for you. Working in Node.js, create a file called “patchcore.js" in a test wiki with the following content: /*\ title: $:/PatchCore.js type: application/javascript library: yes Demo of patching the core plugin \*/ (function

[twdev] Re: Feature Request: high-priority "bootloader" module-type

Addendum: If startup modules aren't collectively preloaded before they are run, boot modules may be unnecessary. However, this would force a change in the prioritization mechanism (using tiddler fields rather than export variables). I think there might also be a meaningful difference in scope