We should probably have a basic loading-a-page screen before 0.8. We should have both a javascript version and a non-javascript version.
Lets start with the non-javascript version: - The user clicks on a link. - We start a request. - We can either wait, or we can show a progress screen. - If the user-agent isn't recognised as a browser, or has an Accepts line which doesn't include HTML, or we are configured not to use the loading screen, we wait, and impose the 2MB maximum size limit. - Otherwise, we decide whether to wait or not based on the progress of the request. - If we choose not to wait, we send a progress screen to the user. We include the known MIME type, filename, and size, and an option to background the download. We include a progress bar, and an indication as to whether there are likely to be more progress bars. We ignore the size limit. We send a 5 second refresh, and if we don't get a re-request in 10 seconds, we kill the request: the user has presumably navigated elsewhere. We will probably need to include some sort of session identifier in the URI while we are loading, although when the download is finished we can remove this. Criteria: - If we are loading blocks from the datastore only, and there are fewer than some threshold (2MB? more?), we wait. - If we are fetching blocks from the network, and there are more than some number, we show the progress screen. - In general, we should show the progress screen if we think the request will take more than 5 seconds to complete. A javascript version would have further advantages: - We could know immediately if the user left the page. - Provided we are close network-wise to the requester, and we have support for a recent version of javascript, we could connect to the node via a socket and obtain real-time status updates. We could then not only update the progress bars etc in real time, we could entirely avoid any extra latency from the progress screen, going immediately to the download when the data has been found. - When I last looked into it, I found that firefox does not support MIME replacement for inline images - only for full-screen images. Therefore the only way to make inline images load progressively would be via javascript. It would make sense: we could show a percentage and a progress bar, even on a small image activelink. The javascript would cause the images to be reloaded when necessary. What would be even more impressive would be if we were to implement some simple media filters, so we could stream mp3s for example straight to the browser without having to query the user about them. Then you click on Chaos Radio, click on a page, click on the button to download the mp3, you get the loading screen for a few minutes and then the mp3 goes straight to your browser and plays. An mp3 filter would be relatively straightforward; an ogg filter would be a bit more work but wouldn't take a long time either. RSS would be more work, but freenet/miro would be pretty impressive. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081217/2cee95d0/attachment.pgp>
