Matthew Toseland wrote: > 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... > If not, then FCP over HTTP, which extensions can presumably do. >> 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 [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
