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>
