Dicho por Troed S�ngberg: > On Fri, 31 Oct 2003 15:57:49 +0000, Ian Clarke <[EMAIL PROTECTED]> wrote:
>>> freenet:// handled by Opera, Firebird etc. If Freenet isn't installed, >>> a redirection to http://freenet.sf.net where the download links are >>> more prominently displayed. >> >> We have debated the whole freenet:xxx thing before and there are serious >> problems with it - not least of which that it will force us to start >> maintaining a different Freenet plugin for each version of each >> different web browser, this could rapidly turn into a support nightmare. >> Combine this with the fact that there is little other than an asthetic >> benefit to this. > You asked what is needed for general acceptance of Freenet, I replied. > I've advocated Freenet for a long time along my peers (I'm a professional > Software Engineer, specialising in crypto/security issues) - and trying to > get people to visit links to http://localhost:8888 isn't working. Other > programs (e2dk:// I believe) do this - Freenet needs it as well. Many p2p app have by now his own link types for downloads. It's waiting to happen in freenet. Ian wrote: > Freenet URLs are much more likely to be given to people in hyperlink > form, in which case the actual form of the URL isn't particularly > relevant. The whole freenet:xxx thing is purely cosmetic. While I agree that freesites can (is there another way?) be passed around in http:// links, I think the downloadable media needs the possibility to be managed by any program. If you define a standard link for media in freenet intended to be downloaded instead of displayed (think of videos, mp3, zips and co.) other apps can take the bait. Think of fuqid, I rarely use the web interface for large files. These kind of apps are bound to appear if freenet gets popular, and they will need this kind of feature. Another approach could be something like http://localhost:8888/<some kind of identifier><freenet key> or maybe http://localhost:8888/<key>?manage+as=download or something along these lines (there are already parameters passed to fred this way, right?) and let fred spawn the approppriate app. This don't require browser/OS associations but only a tab of app associations somewhere in fred configuration. I'm thinking now only of downloads, but maybe there are other needs which could require more generalization. Thoughts? _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
