[EMAIL PROTECTED] 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
[email protected]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[email protected]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[email protected]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
