On Friday 28 March 2008 12:45, Obey Arthur Liu wrote: > I think what you found was about netscape-style plugins. It seems that > firefox-style extensions are a very different beasts : > <http://developer.mozilla.org/en/docs/Extensions>
That's extensions, not plugins. Extensions are written in javascript. I don't know whether they are able to open TCP connections... > I'll look up how much work is needed but it doesn't look *that* bad, > plus there is a lot of open-source code with similar functions to read : > <http://developer.mozilla.org/en/docs/Code_snippets:Progress_Listeners> > > Matthew Toseland a ?crit : > > Hmm, this is nice ... the plugin API docs were hosted by AOL, AOL took it > > offline, mozilla.org switched to archive.org, which only has the index page. > > So right now there is no documentation for the plugin API! It looks like it > > may be a fair amount of work certainly for somebody who doesn't know the API > > already. > > > > http://www.mozilla.org/projects/plugins/ > > http://web.archive.org/web/20040203041440/http://devedge.netscape.com/library/manuals/2002/plugin/1.0/ > > > > On Friday 28 March 2008 01:04, Obey Arthur Liu wrote: > > > >> Matthew Toseland a ?crit : > >> > >>> On Wednesday 26 March 2008 10:42, Jano wrote: > >>> > >>>> This plus a torbutton-like extension would be nice. > >>>> > >>>> > >>> What would you suggest that any such extension would do? > >>> > >>> > >> Hijack ahead. > >> > >> I read the thread so far and I think that the extension solution is the > >> most viable. > >> * Firefox profiles has proven unstable. It clearly has never been > >> designed for shipping "custom navigation profiles". > >> * Hacking javascript handling into the html code involves tampering with > >> the data, which is not good. I'm not sure it would help either. What > >> would it do ? Rewrite the DOM-tree asynchronously ? That would > >> fundamentally be like rewriting part of Firefox in Javascript (!). > >> * Changing the behavior of the http server to make Firefox behave > >> differently seems contorted and unreliable. I mean, make the server > >> behave *very* oddly to influence the client into working differently ? > >> * Shipping a portable Firefox would be problematic in regard of updates, > >> size, code to maintain.. Would work under Linux though (compile it all > >> static and patch it with custom profile paths...) but we'll probably > >> have to call it freefox or icefreeweaselnet or... > >> > >> An extension would solve most problems in a manageable way. > >> This extension would : > >> * allow a much higher number of connections to the freenet http server > >> * replace inline images with special images : requested on freenet, > >> loading chunks, unavailable...; and would turn into the original image > >> when available > >> * display a status panel (sidebar ?) with the status of each element on > >> the current page > >> * maybe provide other miscellaneous useful functions such as detecting > >> plain-text CHKs and offering (contextual menu ?) to send it to Frost or > >> FUQID for example. > >> > >> This extension would be activable per-window (or maybe even per-tab ?), > >> would be visible when activated (different address box color..) and > >> would inherit settings to child tabs/windows. > >> > >> > >> This would need some sideband access to the Freenet node but should be > >> manageable on the node side. > >> Most individual functions already exist in some form in other extensions > >> : per-site exemption for fasterfox exists somewhat, inline images > >> replacement exists (there's an extension called My Image Here)... > >> > >> I don't believe a reasonable server-side solution can be found that > >> would attain similar objectives short of shipping 50kb of Javascript > >> with each html file and some other reasons. An extension at least is a > >> clean solution, it would be the most fitting into the design of Firefox. > >> It wouldn't be the easiest to do but would provide a solution that > >> doesn't look like a stop-gap one. > >> > >> What would you think of such a GSoC proposal ? > >> > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Devl mailing list > >> Devl at freenetproject.org > >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080328/e4afd253/attachment.pgp>
