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.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.


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.
>

A minimal implementation of bootloader modules would look something like 
this:

// Run bootloader modules
$tw.modules.forEachModuleOfType("bootloader",function(title,module) {
if(module.boot) module.boot();
});

This would go right before "startup" modules.  Lack of prioritization and 
"one by one" execution is less than ideal but still preferable to the 
current constraints.

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.


At this point, I don’t see any problem with your plugin duplicating a few 
> hundred lines of boot.js.
>

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.


On Monday, 12 February 2018 15:10:16 UTC-6, Jeremy Ruston wrote:
>
> 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 justified at 
> present.
>
> Better to work with the plugin for a while, and explore the capabilities 
> and consequences before we commit to a new mechanism in the core.
>
> So, as mentioned in the OP I'm pretty leery of the "pre-boot" approach 
> here.  The modloader process 
> <http://evanbalster.com/tiddlywiki/formulas.html#%24%3A%2Fplugins%2Febalster%2Fmodloader%2Floader.js>
>  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.
>
>
> At this point, I don’t see any problem with your plugin duplicating a few 
> hundred lines of boot.js; eliminating such duplication would come firmly 
> under the heading of optimisation.
>
> 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). 
>
>
> You can see all the code that depends on this stuff. The approach is solid.
>
> The current modloader can manipulate almost everything in the wiki 
> *except *for startup modules and the modules they require, hence the 
> request.
>
>
> Yes, but your proposed solution is just an escalation in an ongoing arms 
> race to be the first module to run.
>
> 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.
>
>
> But equally, there’s no limit to the functionality in the boot kernel that 
> experimental plugins might want to tweak. Better to be based on a pre-boot 
> hook, and have the capability to hook anything, than to be dependent on the 
> hooks anticipated and provided by the core.
>
> Best wishes
>
> Jeremy.
>
> So, as mentioned in the OP I'm pretty leery of the "pre-boot" approach 
> here.  The modloader process 
> <http://evanbalster.com/tiddlywiki/formulas.html#%24%3A%2Fplugins%2Febalster%2Fmodloader%2Floader.js>
>  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.
>
> I expect we'll end up discussing in more depth during tomorrow's call.
>
> On Monday, 12 February 2018 14:09:17 UTC-6, Jeremy Ruston wrote:
>>
>> Here’s the .tid of the $:/PatchCore.js tiddler, too.
>>
>> Best wishes
>>
>> Jeremy
>>
>>
> -- 
> 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 <javascript:>.
> To post to this group, send email to tiddly...@googlegroups.com 
> <javascript:>.
> 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
>  
> <https://groups.google.com/d/msgid/tiddlywikidev/98a6ce14-9ba5-470d-b396-365f08ddd806%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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.
To post to this group, send email to tiddlywikidev@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/cf2e1886-225d-49a0-9232-c646ee5352f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to