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> 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: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080328/ea631041/attachment.pgp>
