I would personally like to see a solution that starts with ALL user content loaded in a skinny form eg. title and tags, possibly fields, with the exception of systemConfig tagged tiddlers and maybe overriden shadow tiddlers. I think this is important as a lot of plugins make use of tagging and it might be important to load all tags firsthand.
A javascript dictionary object is also created that indicates the status of whether content has loaded we'll call this tiddler_status. I then imagine a world where before any tiddler is used (possibly this would be in store.getTiddler(), a check is made to see whether the content has been loaded yet and if not it is pulled in eg. if(! tiddler_status[foo]) load the tiddler using ajax. It could be interesting if random tiddlers are loaded during times of inactivity while the user browses the tiddlywiki, I think the important thing is the initial load time, as I am greatly put off by TiddlyWiki sites that take a long time to load. Mine using ccTiddly is terrible and I'm desperate for a decent solution here. As another talking point, maybe a stupid suggestion (it's getting late and I'm maybe not thinking clearly after a glass of wine) would it yield faster results if tiddler data instead of being written to the dom was written to the store in javascript world in the head of the document as packed javascript and added to the storeArea div when required by displayTiddler? I know writing lots of dom elements causes quite a big slow down so this might speed loading time up but I'm not sure whether this would be easy to modify TiddlyWiki to do. Anyway probably stupid... :) That's my 2 cents. 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. > > This is by no means a new topic and FND pointed me at a thread > summarizing an experimental implementation in > ccTiddly:http://groups.google.com/group/TiddlyWikiDev/browse_thread/thread/617... > > In fact, more recent topics on the ccTiddly group suggest Simon is > continuing to tackle this problem; so there is already an approach we > can gain insights from. > > 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. > > It might help to distinguish two approaches to delayed loading of > tiddlers (corrections appreciated): > > *lazy loading: After first opening the wiki, the starting tiddlers are > loaded, and additionally the client is sent the names of all the other > tiddlers on the server. > -This is done using skinny tiddlers which are essentially just the > title (and meta data?). It amounts to sending a table of contents to > the user when they first load the wiki, and later filling in tiddler > bodies upon request. > -The initial load time depends on the number of tiddlers in the wiki. > > *load on demand: After first opening the wiki, the starting tiddlers > are loaded, but no information about other tiddlers on the server is > sent to the client. > - How this would be done remains to be seen. > - Initial load time is independent of the number of tiddlers. > > 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. > > Load on demand should provide constant load time no matter how many > tiddlers are in the document. Theoretically Wikipedia could be stored > in a TW and the initial load would still be snappy. > > I think the problem of implementing either of these methods can be > divided into two main questions: > > 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,. > > Question 2 brings up the trade off that comes with delaying tiddler > loading: namely waiting for tiddlers to load when links to tiddlers > are clicked. > > In general it would be nice to get the benefit of a quick "boot up", > while still preserving the seamless navigation we get with a > standalone TiddlyWiki (tiddlers show up the moment you click them). > > 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. > > For now I've conveniently ignored any painful realities and stuck to > concepts. Please correct anything you find inaccurate, I've actually > written this post while knowing very few details. > > Hopefully the core devs and others can give their input and we can > move towards some concrete aspects of developing the feature in > TiddlyWeb. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
