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 ?
>>>>
