Matthew Toseland wrote:
> On Friday 28 March 2008 03:57, you wrote:
>
>> * Obey Arthur Liu <arthur at milliways.fr> [2008-03-28 02:04:50]:
>>
>>
>>> 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 ?
>>>
>> It's not a three months job, hardly a 3days one for someone who knows
>> firefox's internals.
>>
>
> Some of the things he mentioned probably wouldn't be feasible in a browser
> plugin. And some would be hard e.g. making javascript safe given some user
> specified parameters, although that would be *slightly* easier than doing it
> on fproxy. Presumably firefox plugins have a well established and limited
> API, this would help with maintainability but on the other hand it means
> several things listed above probably wouldn't be possible: we'd still have to
> filter the HTML for example in all likelihood. We'd have to expose it through
> FCP, and just have a freenet: protocol handler plugin which uses FCP (and
> would need a config dialog somewhere).
>
If a Firefox extension can handle a freenet: protocol handler, then we
wouldn't need a full fledged plugin. As I understand things, an
extension is cross-platform by default (interpreted code) whereas a
plugin is always platform dependent (compiled code). So we just need to
check that Firefox extensions can be a protocol handler and then start
implementing FCP support in Javascript.
>> I'm reluctant to deal with a browser extension because maintaining it
>> *will* be a PITA.
>>
>
> Not if there is a well established and clean API. Which there should be by
> now; there must be, really, otherwise there wouldn't be so many substantial
> plugins available.
>
--
David R. Sowder, Linux Systems Admin (Software Systems Specialist II)
Office of Information Technology, University of Texas at Arlington
Work: 817-272-1081 davids at uta.edu http://www.uta.edu/
davids at talk.uta.edu (Jabber)
Personal: david at sowder.com http://david.sowder.com/
