>interesting. Why did otrunk.jar take noticeably longer than other >resources to download?
I suspect it was a random network or server slowdown. What's more interesting to me is the very low bandwidth efficiencies when transferring smaller jars and jardiffs -- that's something that could be improved changed and tested. Investigating a problem in an ITSI school (science teachers across the whole district were all working with ITSI at the same time) -- we noticed that a few transfers from the jnlp server to a users computer failed (dropped connection) -- the problem was the JWS client didn't check to make sure the whol payload was transferred and just handed off the download to the unpacker which handed that off to the un-gzipper -- which threw an error. The server delivered the size of the download in an initial header so the JWS client could have known the download didn't complete and tried again to complete it -- and if that failed provided a better error message -- or even use an older set of jars if they had been downloaded successfully. It's crazy that this isn't in code we can easily fix. We need to use a different distribution mechanism than the JWS built into Java. I'm thinking we should deliver a Java application that implements it's own version of JWS that works better. The user experience could be MUCH better -- and it desperately needs to be much better. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" 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/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
