junk at giantblob.com wrote: > What about this for a glorious kludge? > large file downloads from fproxy actually trigger the 'download' of a > modest size dummy file, the progress of which is matched to the progress > of the actual split-file download - this provides the users' standard > browser UI/feedback for a download > when the download is 99% complete, fproxy redirects the browser to a > link to the actual download, which then completes instantly
Seen that this idea hasn't been well received, I suppose mine will neither, but I must try ;) Given that all the downloading/assembling is done inside the node, you just give to the browser a standard download connection[*], and make available the data that is available contiguous from the start of the file. This surely means that the download will go in jumps when holes are filled, and it may seem stalled for some time, but at least you have a regular download whichever the browser. The API for 3rd party apps allows for more detailed download managers/multi-node downloads for those entrepreneur developers. I really think that, even if some quantity of rounding squares is needed, providing a standard download is in the benefit of freenet. However, a "download feedback page" is too a deviation from standard behavior, and I agree that it should not be repeated. Giving a standard download connection would allow too for cancelling downloads in the usual way. Depending on the circumstances, I could even have some time to implement this if feasible and nobody is interested in future months. [*] I just mean answering to the request with a standard HTTP reply, and provide the sequential data when it's available. > -- jeek > > Colin Davis wrote: > >> I just fail to see what an applet gains that can't be done with an >> XMLHttpRequest and a properly written webpage. This is a file that's >> going to be downloading over minutes/hours. We don't exactly need up >> to the second status updates, and even if we did, we can do that >> purely in the browser. >> >> >> There's UI tricks you could do to make it less difficult to check, if >> you really wanted to go that route. You could have a fproxy option to >> append a frame onto the side/top of all pages, similiar to the >> GoogleCache frame. >> I'm note sure of the feasibility, but couldn't the you feed one or two >> bits / second to the download, just enough to make it not time out? >> That way, when I click a link in fproxy, it starts a download, in my >> browser's exsiting download manager. Freenet continues to feed one or >> two bits of garbage/whitespace/whatever to the download every few >> seconds, to prevent a time out. From my perspective, it would look >> like any other download, just take a long time. When freenet >> internally finished downloading the file, it can just give the rest of >> the bits to the browser, which thinkgs it's been downloading the whole >> time. >> >> These are just examples, and not very good ones at that. But there's a >> lot of things that /could/ be done to make it feel like it belongs in >> a browser. >> >> Just a few random thoughts, >> Colin >> >> >> Matthew Toseland wrote: >> >>> Well, the more paranoid will certainly disable applet support in their >>> browsers... >>> >>> On Wed, Aug 31, 2005 at 05:32:50PM +0300, Constantine Dokolas wrote: >>> >>> >>>> Ian Clarke wrote: >>>> >>>> >>>>> The correct solution is using a "Freenet aware" third-party client >>>>> that doesn't require us to hammer the square peg of a Freenet >>>>> download, into the round hole of a web browser. The "web >>>>> metaphor" is all very well when it is appropriate, but in the case >>>>> of the download of large files from Freenet, it simply isn't. >>>>> Better to do it properly than to impose >>>> >>>> >>>> >>>> >>>>> an inappropriate metaphor where it doesn't belong. >>>>> >>>> >>>> >>>> I've been following this thread, but I still don't see why the >>>> download progress page can't be handled by a simple (which may be an >>>> understatement) applet. I haven't heard anybody mention that >>>> possibility yet and I don't know why everybody is stuck in the >>>> HTML-or-full-blown-client way of thinking. >>>> >>>> Doc >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Devl mailing list >>>> Devl at freenetproject.org >>>> http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl >>>> >> >> _______________________________________________ >> Devl mailing list >> Devl at freenetproject.org >> http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
