This post became pretty big, hope you guys can stay awake :) > 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.
To begin with I assumed the server is always going to be there. At the least I think we have to assume the server is available for the initial load, else the user won't even be able to start doing anything; that is unless there's a provision for working offline with a local standalone copy. If server availability is a question mark then the ability to fall back to standalone mode would allow work to continue till the server is accessible again. > What, in your estimation, are things that are gained by sending the > list of tiddlers at load time? As you noted, the tags and timeline are big ones. Both could be especially important for newcomers unfamiliar with what content is available on the site. That would then require skinny tiddlers (title plus field meta data). If we're absolutely focused on the fastest possible load, maybe we could do a hybrid loading process, something like: * First load the default tiddlers / initial tiddlers * Then proceed with background loading: ** Prefetch tiddlers linked from currently open tiddlers. This step would repeat each time a new tiddler is opened. ** Proceed to download the remaining tiddlers in "skinny" form allowing the remainder of the timeline and list of tags to be filled in. Or a slower simplification of the above: * First load the default tiddlers in full along with the rest of the tiddlers in skinny form. * Prefetch tiddlers as necessary. Depending on the size of the wiki, and assuming we want the entire timeline available, the hybrid method may noticeably speed up the initial load by allowing the full "table of contents" to stream in the background in the form of skinny tiddlers while the user starts looking at the content in the initial 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. > > 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: Absolutely. That was an optimistic assumption made to cast lazy loading in a more favorable light when compared to on demand loading in terms of performance. That was when I thought lazy loading was going to be the easier one to implement. I think the effects of the variables you mentioned bears thinking. I haven't had a chance to look at the caching hoster plugin so I'm not sure what role that would play. It would be nice to run some numbers to get ballpark figures on load times for various sized wikis. I'm curious how many tiddlers it would take before transferring a full list of skinny tiddlers starts becoming really noticeable. > http://tiddlyweb.peermore.com/wiki/recipes/docs/tiddlers.wiki?mselect...[[TiddlyWeb%20Documentation]] > > If it's working right, what should happen is the tiddlers are loaded > from the server, as you navigate along them. That's awesome! It's working beautifully! I probably find seeing that in action more exciting than I should. I jumped around clicking several of the tiddly links trying to get a sense of how disruptive the load times are compared to the normal uninterrupted flow of navigation in an offline TiddlyWiki. It's a little hard to assess objectively right now becauses part of me is just excited to see on demand loading working before my eyes. Apart from the linked example I tried using the "filter" tiddler as a starting point which provided a nice avenue for exploration. I kept Firebug open and watched the latencies of the GET requests. On average they were below 1 second, most in the range of 600 to 800 ms. My initial impression is that load times in that range are acceptable, but I don't know whether that will hold up in the long run. Based on the definitions from the initial post this is really a fully implemented form of load on demand functionality. Contrary to what I originally thought lazy loading is actually the option that would require more work, is that right? I looked in the core to try to get a more concrete picture of how these things are implemented in TiddlyWiki. If I'm not mistaken, load on demand is actually the natural mode of operation for TiddlyWiki's core adaptor mechanism. Clicking a tiddly link starts a chain of function calls beginning with the onClickTiddlerLink() event handler. If the tiddler isn't found in the local store area, the Story object's loadMissingTiddler() function gets called which in turn invokes the TiddlyWebAdaptor via the SyncMachine. The SyncMachine performs a few steps; it executes some of the adaptor's methods including the adaptor's getTiddler() method which sends an HTTP request to the TiddlyWeb server. If the server finds the requested tiddler it is sent back in JSON serialized format. That's roughly my understanding of what happens on the client-side. It appears load on demand is a byproduct of implementing the adaptor interface. On a related note, I did see one issue. There's no notification when a tiddler doesn't exist. Upon opening a tiddler it initially appears with the message "Attempting to retrieve the tiddler..." and even when the GET returns a 404, the same message continues to display with no indication that anything happened. To summarize: As far as load on demand is concerned it seems what actually needs work is how to send just a subset of tiddlers initially (and which ones to send). Is that accurate? For lazy loading it's additionally necessary to add support for handling skinny tiddlers because the adaptor does not handle or recognize them by default. Also using the hybrid loading approach I think the perceived performance of lazy loading could match that of load on demand. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to TiddlyWikiDev@googlegroups.com To unsubscribe from this group, send email to tiddlywikidev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
