Kacheong Poon wrote:
Darren Reed wrote:
...
So how does this relate to what we should do with Solaris?
*IF* you wanted to steer away from making something
Solaris specific, I'd argue that one approach would be
to adapt programs such as web browsers to send out a
request for the http proxy on the loopback interface and
for Solaris to provide a daemon that listens for and answers
those queries with information provided to it via some
"other means".
So this requires changing the apps, right? The obvious
problem is that we cannot change every apps. I suspect
that it may not even be possible to change the bundled
Firefox as this will cause the Sun code base to diverge
from the core one.
Well what value will whatever you do to discover
network proxies automatically have if I still need
to change $http_proxy myself, every time I connect
to a new network? I want network automagic to work all
the time, not just some of the time or when it feels
like it. The task at hand for Sun then is to feed
back our changes to the open source community
so that they become part of the original distributions
and thus descreases our overhead of maintainance.
What value is it to have Firefox work but Mozilla not?
or wget not? or ftp not? or...with the program yet?
We need an architecture designed to make this work so
that it can be applied to all applications that can
function today using proxies.
That "other means" could be broadcasting on the network
itself, to find the answer, or reading data from a config
file or using the GNOME interface.
Another approach might be to just have applications use
UPnP directly to the LAN, without having a middleware
daemon run on Solaris.
So some pros and cons with this approach:
pro - it implements an "industry standard" protocol;
con - it's not a simple solution;
I guess it is a solution for a bigger problem.
Yes.
pro - the work undertaken by Sun could be contributed
back to the open source community;
con - it requires changes to all programs that currently
use proxies;
This is the key problem. Even if we contribute back to
the community, a lot of apps still may not be changed to
use it.
If we can come up with a good idea and a good architecture
that we can provide back to the community as an independant
project then hopefully others will adopt it and make it grow.
This would mean spinning this part of NWAM out as something
featured seperately on sourceforge.net, even if only as a leaf
of this part of the project. I'm mentioning sourceforge.net
here because we currently appear to have no capacity to do
what's required here within opensolaris.
pro - if a daemon is developed, we increase our position
as a worthwhile platform in the network appliance
space;
...and so on...
Note that we are also looking at other similar types
of technologies, like Bonjour.
That's good to know.
FWIW, Sun's name is already associated with UPnP (but I don't
know who is responsible for that.) In addition, we need to
consider what IP problems we are likely to run into (cross
licensing deals with Microsoft vs what with Apple) given that
Bonjour is Apple's.
In addition, we could think about adding vendor specific
type codes to DHCP for proxies (I'm surprised that there
is nothing in DHCP for this - that I can find- yet) that
are retrieved at bootup and fed into the GNOME thing or
your login shell as $http_proxy, etc.
So this suggestion is about having a "default" environment
variable set for all processes after bootup. But how about
changing it after bootup? How about apps which do not
use this method to obtain proxy info?
Using $http_proxy is what I'd consider a defacto-standard.
If an application doesn't at least use that then I'd consider
it a pretty fundamental bug.
But if you want a run-time method then it needs to work
independant of GNOME, hence the idea of having a daemon
and client libraries to talk to that daemon.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
