On May 12, 5:34 pm, Oveek <[email protected]> wrote: > I'm following up a quick chat with Chris, and FND, on #tiddlyweb, > about delayed loading of tiddlers. The aim is to discuss possible > implementations in TiddlyWeb and get started working on one or more of > them.
Glad you started this thread. I think you're smart to try and define the terms up front as there is a lot of ambiguity and in order to really talk about this stuff we need to know what we're talking about. > Just to restate the point of this: the primary motivation is to reduce > the initial load time of a large TiddlyWiki, and generally to improve > scalability. I roughly think of initial load time as the time elapsed > between hitting go in your browser and seeing a fully rendered > tiddlywiki with all default tiddlers displayed. In this use case do you assume that the server is always going to be available; available for at least the initial load time, but maybe not later; or server availability is an unknown. The first option is clearly the easiest. > It might help to distinguish two approaches to delayed loading of > tiddlers (corrections appreciated): [lazy loading and on demand] What, in your estimation, are things that are gained by sending the list of tiddlers at load time? It does lots of things, but it is also possible to get by without it. Try this URL, clicking on some of the links in the list in the TiddlyWeb Documentation tiddler: http://tiddlyweb.peermore.com/wiki/recipes/docs/tiddlers.wiki?mselect=bag:system,title:TiddlyWeb%20Documentation#[[TiddlyWeb%20Documentation]] If it's working right, what should happen is the tiddlers are loaded from the server, as you navigate along them. (I'm just at the end of a train ride, so won't stop to explain what's going on here in this message, but will write more later.) Presumably things like the time line and tag handling are the main wins to be had by providing the tiddler list and metadata. > Both approaches ought to yield major performance improvements. As > noted, lazy loading will incur a small increase in initial load time > as tiddlers are added to the wiki, but this increase should only start > to even be noticeable after adding a large number of tiddlers. This is an assumption that probably deserves some testing to establish if it is true or not. It is going to depend a lot on different variables: * the bandwidth of the user's connection * the processing speed available to the browser when the tiddlywiki is loaded * how long it takes a server-side to "compose" the tiddlywiki server side * whether being lazy or on demand has much impact on that composition time server side * whether the server side is able to do any caching[1] * other things I can't think of right this minute [1] See the caching hoster plugin: http://tiddlyweb.peermore.com/wiki/#cachinghoster > 1) What gets loaded initially? > Default tiddlers, plugins, etc,. > > 2) How are requests handled after the initial load is done and the > user starts interacting with the wiki? > This concerns retrieval of additional tiddlers, searching, etc,. Yes. > I noticed in FND's thread the nice idea of streaming tiddlers in the > background. I think a cool variation would be to stream or "prefetch" > only tiddlers that are linked from the currently open tiddler(s). This > might achieve a compromise between not transferring unrequested data > and trying to maintain smooth navigation. Anyway that's for later > consideration. That's a good idea. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
