After an extensive discussion on #extdev on irc.mozilla.org, I have determined that we could probably do what we need to do in a Firefox plugin, but it is clear how or whether we could prevent normal web sites from loading freenet content and timing it to determine whether the user has visited it.
nsIProtocolHandler - this is the interface we would need to implement in our FCP engine. The browser calls newChannel(uri). nsIChannel - this is what we get from newChannel. Firefox configures the expected MIME type. This is how the HTTP protocol knows to send different Accept: headers for inlines versus for page loads (from typing in the url, clicking a link etc). This is vital because we cannot show an HTML-based page loading screen for inline images! Whereas if the user typed in, or did right-click-view-image, we DO want to show a loading screen. It is possible for javascript code to talk to the backend via either JSON or XML. Exactly how needs to be researched, but extensions can and do talk to javascript on pages. This would allow us to implement a fast and attractive page loading screen. It is also possible to remove pages from the browser history, this is essential for us to avoid browser history stealing from other websites: nsIBrowserHistory.removePage(uri) We can thus implement an FCP-based backend to handle freenet: URIs, we can treat inlines differently from full-page loads, and we can show a loading screen. Inline images initially will not need a loading graphic, since there is no connection limit for FCP (the HTTP one is implemented at the level of the HTTP protocol handler). If we wanted to have one it would be possible to do it in javascript. However, we would still need to worry about webpages accessing freesites - this is essentially an XSS attack, something like : <img src=freenet:u...@some-controversial-site/ onLoad=[ report to website ]> I don't know if it would be easily possible to prevent this with a browser plugin - it could probably be done with some hacking. Disguising the fact that we are running a node at all may be more difficult, especially given all the javascript or HTML-based port scanning attacks. I haven't been able to actually run any of them successfully so far. In an XULRunner or webKit-based app, we wouldn't have these last problems. However, much of the architecture would probably be the same if we were using XULRunner / MozSwing, so these URLs may still be useful: https://developer.mozilla.org/En/NsIProtocolHandler https://developer.mozilla.org/en/NsIChannel https://developer.mozilla.org/en/nsIBrowserHistory http://www.nexgenmedia.net/docs/protocol/ https://developer.mozilla.org/en/Document_Loading_-_From_Load_Start_to_Finding_a_Handler Lobo java-based browser: http://lobobrowser.org/java-browser.jsp Ian is of the view that the poor rendering quality disqualifies Lobo, and prefers Mozswing: Mozswing (XULRunner wrapped in java): http://www.mozdev.org/pipermail/mozswing/ http://sourceforge.net/projects/mozswing http://blog.limewire.org/?p=303 http://mozswing.mozdev.org/ AFAICS Mozswing is a wrapper for XULRunner, allowing you to access or implement ns* APIs. This may explain the lack of documentation. Meanwhile saces is working on wxFCP. IMHO this is the best option, because I don't have to do all the work - but it is true that I'm not a great C++ coder. It is also true that I have less experience of coding GUIs than of coding C++.
pgpyEth2DOiPN.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
