> It seems to me that having a single update function that takes a bunch of keyword arguments, only some of
> which can be used together, is not optimal. On the other hand, I can see that it is the easiest to
> implement since it also maps most closely to the Mozilla prefs. An alternative interface would be to
> have separate functions for each proxy type, e.g. new http_proxy("whatever", $port = <optional port>)
> or new socks_proxy("whatever", $port = whatever, $remote_dns)
>
> or new auto_configuration_proxy(...);
Most of the arguments can be used together. If a SOCKS proxy is
specified it will be used unless a protocol-specific proxy is also
specified. So if I specify only HTTP and SOCKS proxies, HTTP requests
will use the former, and SSL, FTP, and gopher will use the latter. The
$ac_* and $mode parameters are the ones that don't quite fit, which is
one reason why they weren't part of the profile in the first version.
However I believe it makes more sense to include them as part of a
profile.
> It does certainly seem that disabling a proxy profile should be handled by switching to a special
> no-proxy profile or something like that. Or maybe this no-proxy profile would just be called null?
Are you suggesting that proxy_disable() be removed and instead using
e.g. proxy_enable(null) to disable the active proxy? I think using a
function named 'enable' to disable is misleading. Having
proxy_enable(null) disable active proxy is fine, but I think
proxy_disable() should remain, even though one will just call the
other.
> Also, why does there need to be a special list of proxy profiles? Why not have proxy profiles simply be
> stored as variables? They could have an optional label field for display purposes.
Internally I envisioned using a proxy_profile object whose properties
were the keywords accepted by 'define', and these would be stored in a
list with contents manipulated by 'define' and 'remove'. Expecting
users to manage these objects themselves would give them more control
and eliminate the need for 'define' and 'remove' thus simplifying the
API. However, I can't imagine any especial gain by doing so
(suggestions welcome), while I can imagine a scenario where doing so
would be detrimental: interactive profile configuration and management
systems.
For example, an interactive command 'proxy-enable', which I hadn't
considered before, but which now strikes me as useful. The alternative
is having users edit their rc files and restart/reinit conkeror, or to
eval javascript, everytime they want to change proxies. If a user has
a proxy on-campus but not at home, and uses conkeror on his laptop at
both locations, it is much more reasonable to have him type into
conkeror:
M-x proxy-enable<return>Campus<return>
...than to have him edit his rc file when he gets to school, and then
again when he gets home.
For another example, someday we may decide to include interactive
profile configuration for users who are uncomfortable configuring a
browser via an rc file.
These examples require a managed list of profiles. Per the first
example, 'proxy-enable' would need to know where to look to find the
profile named 'Campus', which it couldn't do if the user stores his
profiles in some unknown variable, list, map, or object.
Sure, we could merge approaches: keep 'define' and 'remove'
specifically for convenience and for use by interactive systems, and
if the argument to proxy_enable is a string, then consult the managed
list, and if it is a proxy_profile instance, then just use it. Though
I believe this route would confuse things for little benefit, I also
enjoy the liberty of having the best of both worlds.
What do you think?
> As far as something other than the proxy mechanism changing the profile, I don't think the proxy profile
> < ... snip ... >
> current prefs.
Agreed. |