"Nicholas A. Zigarovich" <nicktastic@gmail.com> writes:

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

Okay, I see.  It certainly makes sense then to include all of those
parameters together.

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

Perhaps then the split should just be between a regular proxy profile
and an auto-configuration proxy 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.

Well, it could be called proxy_switch_profile, but proxy_disable is fine
as well, I suppose.

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

Well, for this purpose, I would think the user would want some more
general system that automatically handles all of his programs, and
ideally auto-detects whether he is on campus, since I would think it
would be a real pain to have to do some manual configuration of every
program.

Still, I can see providing an interactive command for proxy switching
with completion a useful thing, so I'll agree that having a special list
is a good idea.