In testing, it appears to stick on some pages/files (but maybe that's just freenet), and obviously it only updates the progress bar and not the rest of the information about a download. I'm guessing maybe failed blocks aren't being reported? I haven't seen any indication of any failed blocks in all my testing, which seems rather unlikely...
As far as I can see, this is the approximate changelog (detailed comments below): Purpose: To use javascript and a single push connection per browser to update various pages in real time. Currently, just the progress page. In future, the connections and queue pages will also be refreshed dynamically, and this work will also form the basis of a solution for the slow inline image loading problem. Generated code: - Everything inside staticfiles/freenetjs/ is generated. The contents of this dir are deleted when running ant distclean. Generating it requires the GWT jars, which compile java to javascript. - The source code for this is currently in generator/js/. - The GWT jars must be in generator/js/lib/. Connection sharing: - One window makes a connection. - Every 100ms, followers process messages from the leader. - Keepalive every 1sec, failover after 3sec. - Failover assigns a new leader, arbitrated by /failover/ on the node (only allows failover from a request ID that was on the awaiting notifications list). HTMLNode generation: - Script formatting. - generateChildren() to render a node's children to a string buffer. - BaseUpdateableElement: base class of any updatable HTMLNode. Has the original ToadletContext, and an updateState() function to regenerate it. - ProgressBarElement: an updatable element for a progress bar. Refactored from fproxy. - Requests have a unique ID, available from ToadletContext, and put in a hidden value in PageMaker. Event tracking: - PushDataToadlet: fetch data from here. - PushNotificationToadlet: poll for updates from here. - PushKeepaliveToadlet: send keepalives here. - FailoverToadlet: arbitrates failover. - PushDataManager: Tracks elements that need updating, elements currently displayed, etc. - Client sends a keepalive every 10 seconds. Anything not received in 21 seconds is pruned. Refactoring: - Factor out FProxyFetchTracker.getFetcher(). Trivial: - 2x test commits. My comments about the code: Synchronization issues in PushDataManager: In the early commits this was inconsistent, are you happy with it now? Hidden input for the request ID (in PageMaker): is this valid HTML? IIRC it's not inside a form? Is separating data from notifications more efficient, even though it involves more round-trips? Re "+" in base64, you could just use a different encoding - the freenet nonstandard base64 for example. You can easily change the base64 code used in the java code to deal with this? OTOH you could avoid it completely with some changes to the wire format... In the cleaner thread: + for (Entry<String, Boolean> entry : new HashMap<String, Boolean>(isKeepaliveReceived).entrySet()) { ... + isKeepaliveReceived.put(entry.getKey(), false); Is this safe? You don't get ConcurrentModificationException's? Please use Ticker rather than java timers, because of thread pooling and thread priority issues. Would it make sense to randomise the failover interval slightly, so that one fails over and then the other two don't need to? You are assuming we will almost never reach MAX_MESSAGES, and in that case the output will just be a little out of date, this is probably reasonable. PushDataManager.awaitingNotifications only contains the "leaders", correct? But all events are broadcast to all leaders? (Javadocs for the variables would be nice) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090617/a381b748/attachment.pgp>