[Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
jvonau at shaw.ca
Fri Aug 10 20:43:07 EDT 2012
On Fri, 2012-08-10 at 15:28 -0700, John Gilmore wrote:
> > > We have no control over the network environment what so ever and need to
> > > work within the confines of what is available.
> > This is our primary constraint: we cannot install servers or proxies.
> > Schools in remote areas have latent/slow/expensive Internet links.
> > You'd think that a caching proxy is common sense. Unfortunately not :(
> > Furthermore, the newer wireless networks treat every client as
> > potentially hostile and hence prevent them from communicating with
> > each other. This also means that no collaboration can take place.
> You *are* sending them XO's or at least XO software loads, yes?
> Fix the XO software with a simple control panel checkbox to make it a
> cacheing proxy access point.
I can see a caching proxy, but without a second network interface I see
no point in creating a access point. The share this modem connection
that is available in Dextrose3 is a great step in the right direction,
but needs to be extended to include any second network interface that
might be added to an XO. That would open up lots of different options
when out in the field at deployment time.
You also must take into account the internet policies that are in place
at the schools, some require individuals to authenticate at their
school's proxy with their userid/password before internet access is
granted. We need to be flexible, there is no one size fits all solution.
> Tell them to configure one of the XOs as a cacheing proxy, stick it in
> a corner on permanent power with its ears up, and have the rest
> connect to that one, not to the provided "base station".
That fits into our bigger plan for a XS like appliance that can be added
to the base fedora/sugar software foundation of an XO with a control
panel applet to configure services offered. I'm looking at the using
avahi to advertise services offered for example a jabber server, a yum
repo, a activities repo, backup space, by the appliance to be discovered
by the client XOs.
> They'll be
> one radio hop further away from the Internet (unless you send 'em a
> USB Ethernet dongle for that XO), but they'll be able to collaborate
> and share, and get much faster access to things that more than one of
> them need.
I agree that a proxy could be setup but the client side on the XO would
still need to be configured to use it. We are dealing with non-technical
people in the field, this would need to "just work" out of the box with
very little work by the people deploying the XOs. For a initial working
model I'm thinking that we could create a new applet to search for
services of interest that are available via avahi and have check-boxes
to enable connections to services that the XO could use. Say for example
discover a jabber server, tick the box for that service and the gconf
key for the collaboration server becomes populated. The proxy service
could be advertised and enabled in the same way. Being able to customize
solutions without having a XS's rigid network layout becomes a whole
pile easier and opens up numerous possibilities in the field.
> If there isn't enough storage on those XOs to make a decent cache,
> send 'em a 16GB USB stick or a similar SD card too.
I think that would be a good option with the above planned appliance as
we need a place to store/serve data from.
More information about the Devel