Hi TheDiveO On Sat, Sep 27, 2014 at 11:18 AM, TheDiveO <[email protected]> wrote:
> Thank you very much Jeremy for describing the issues that need to be > considered. This really helps me understanding TW5 better. It's the > incredible dynamic and flexible behavior of TW5 that makes me pondering > about module hot plugging, but not general module hot plugging, but for > macros, parser extensions, and those other modules where I may get away > with triggering a rerendering. You mention some caching in the boot kernel > ... would that "interfere" with hot plugging those simpler modules? > Yes, the module caching mechanism would need overriding. Basically, TW5 implements the same semantics as Node.js for the require function; requiring the same module a second time returns the same exports object. > Is there a way at this time to reparse and thus rerender the story view > and also the other UI parts without loosing too much state? I have to admit > that even after reading the architecture documents I still don't fully > understand the main core functions, that is, how it keeps certain > dependencies and uses them for selective updates. So please bear with me > asking about the core... > That's the "warm start" I was referring to above. I don't think there's much reason to try to optimise how deep the warm restart goes. As long as the tiddler store is retained all the UI state will be faithfully preserved over a rerendering. The trouble is that adding this feature is guaranteed to change the semantics of plugin startup. Therefore we'd be advocating people developing in a different environment than that encountered by end users using the plugin. That seems like a bad idea. It's one of those things that can be rigged to operate in some circumstances some of the time, but very hard to give any guarantees. That isn't a good platform for developers to work on. But overall I'd recommend spending some time analysing the boot kernel in detail. I'm sure that you'd find it pretty straightforward given the level of knowledge of TW's internals that you are already demonstrating. The questions that you're asking here are not amenable to simple answers because the implications touch almost all components of the system. I think you'd find it much more instructive to do a read through of the code with your questions in mind, and consider for yourself the impact of the changes you're considering. If you raise questions as you progress through the boot kernel then we can address them in the /dev wiki and perhaps make the journey a bit simpler for the next person, too. Best wishes Jeremy. > > Am Samstag, 27. September 2014 10:30:21 UTC+2 schrieb Jeremy Ruston: >> >> > changing a stylesheet tiddler immediately becomes live. Unfortunately, >> this isn't yet the case when editing a module tiddler. I can understand >> that this wasn't on the requirements list so far as the traditional >> development cycles involves external code editors and reloading. >> >> The problem doesn't really have anything to do with the "traditional >> development cycle". The issue is that reloading a module isn't in general >> semantically well defined - any more than it would be under Node.js. The >> side effects of executing a module are strictly limited to returning the >> exported properties; there's no problem with re-executing a tiddler to get >> a revised set of exports, but the issue is what one would do with those >> exports (actually, there is an issue: as with Node.js, the exports of a >> module are cached by the boot kernel). >> >> Each type of module is used differently. Consider dynamically updating a >> parser module: one would expect that all tiddlers would need to be reparsed >> (and the page template re-rendered) in order to apply the modified parsing >> behaviour. Or consider a modified deserialiser module: all tiddlers would >> need to be deserialised afresh to assimilate the change. >> >> Clearly, one can imagine some modules that could be hot-swapped, but I >> don't think that could be done reliably with any of the module types >> included in the core. If one introduced a new module type that was >> semantically amenable to hot swapping there's nothing stopping the code >> that manages those modules from supporting it. >> >> In general, the only reliable way to assimilate a module change is a >> restart. Conceivably one could implement a sort of warm restart in the boot >> kernel, but it would have to do almost everything that a cold restart does. >> >> Best wishes >> >> Jeremy. >> >> >> >> >> >> On Fri, Sep 26, 2014 at 9:35 AM, TheDiveO <[email protected]> wrote: >> >>> On Thursday, September 25, 2014 11:05:27 PM UTC+2, Andreas Hahn wrote: >>>> >>>> I think the easiest way to do this is to trigger a refresh/reboot and >>>> it is also a way that is least intrusive towards the TW architecture. The >>>> refresh would have to maintain the current story view, but i think thats >>>> doable. >>>> >>> >>> This (reload) is exactly what I want to avoid while in the Third Flow. >>> >>> >>>> The second possibility would be to re-evaluate parts of the boot >>>> process, but I have no idea how much you would actually need to do here. >>>> >>> >>> It is clear to me that reevaluation is not possible under all >>> circumstances, but most of the development I did so far were about neatly >>> encapsulated and (mostly) independent modules, so reevaluation seems to be >>> perfectly within reach. So my question is about whether this may be >>> possible already but hasn't yet been triggered so far. >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/tiddlywikidev. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Jeremy Ruston >> mailto:[email protected] >> > -- Jeremy Ruston mailto:[email protected] -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
