Re: [system-tools] CVS Branched

[Carlos Garnacho <carlosg gnome org>]

Hi!

On Tue, 2004-08-10 at 22:14 +0000, Juan Luis Baptiste wrote:
> On Monday 09 August 2004 10:35, Carlos Garnacho wrote:
> > Hi Juan Luis :)
> 
> Hi,
> 
> >
> > Sure, my idea was to show already in the XML the whole list of available
> > supported interfaces (a la ifconfig -a) in this fashion:
> >
> > <interfaces>
> >   <interface>
> >     <dev>eth0</dev>
> >     <type>TYPE_ETHERNET</type>
> >     <enabled>0</enabled>
> >     <configuration>
> >       <auto>0</auto>
> >       <bootproto>dhcp</bootproto>
> >     </configuration>
> >   </interface>
> >
> >   <interface>
> >     <dev>eth1</dev>
> >     <type>TYPE_WIFI</type>
> >     <enabled>1</enabled>
> >     <configuration>
> >       <auto>0</auto>
> >       <bootproto>none</bootproto>
> >       <address>192.168.2.21</address>
> >       <netmask>255.255.255.0</netmask>
> >       <network>192.168.2.0</network>
> >       <gateway>192.168.2.1</gateway>
> >       <essid>my_essid</essid>
> >     </configuration>
> >   </interface>
> >
> >   <interface>
> >     <dev>irlan0</dev>
> >     <type>TYPE_IRLAN</type>
> >     <enabled>0</enabled>
> >     <configuration/>
> >   </interface>
> > </interfaces>
> >
> > Instead of letting the frontend to add any interface (even if it doesn't
> > exist in the system), you already have a closed list with all the
> > existing interfaces (and types) and you only have to worry to
> > fill/modify/clear the <configuration> tag. It IMHO fixes:
> >
> > - better support for still unsupported interfaces: for example,
> > slackware has no way of configuring irlan interfaces, this way we can
> > prevent those interfaces to be shown in the frontend, and thus, to be
> > configured too
> >
> 
> Yeah, I didn't really get it why it was possible to add interfaces even if 
> they didn't exist in the system, it's better to only be able to configure 
> existing ones, unless we can _really_ add them, and I mean hardware 
> autodetection, module loading, modifying /etc/modukes.conf, etc, and then 
> configure the _really_ added network interface. 
> 
> This is more like a feature request :) we could use some hardware detection 
> library, like libdetect from harddrake project [1] from Mandrake, it is 
> really great and portable, it even works in other hardware platforms like 
> powerPC and Alpha. And there are already debian packages of it :)

wow, well... I'd think that it could be a whole project/tool itself,
handling new hardware consistently though every already supported Linux
distribution (plus FreeBSD) seems really hard, but I'd bet for HAL for
making such hardware detection, as it aims to be much more consistent
through various OS (and is desktop independent :)

This could be planned for a really longer term, though

> 
> [1] http://www.mandrakelinux.com/harddrake/
> 
> > - better support of odd OS (compared to linux): for supporting somewhat
> > correctly FreeBSD, the network frontend has to ask the correct interface
> > name for a given type when creating an interface through the
> > "get_interface_name" directive (we can't hardcode eth for ethernet
> > interfaces, it can be dc,bfe,ed...). This way all this info is already
> > in the XML
> >
> why then it's already a <dev> entry in the xml file? isn't this one the one 
> wich informs the name of the interface being configured?

The problem is when you create a new <interface> from scratch, the <dev>
tag is filled right now in the frontend, which terribly breaks the
concept of system info ignorance in the frontend side :)

right now the frontend has to ask to the frontend the interface name
based on the interface type, and with that info it fills the <dev> tag
[1], this is really necessary for having FreeBSD working as it should,
but is indeed a crappy solution :)

In the way I propose that info is already filled, so you'd only need to
fill the configuration part, not the hw/driver dependent side too

> 
> > - better support for wi-fi cards: it happens the same, they can be eth,
> > wlan, ath... and instead of asking to the backend we can have already
> > this info.
> >
> 
> Are there any plans to support more wi-fi info like WEP keys, speed, operation 
> mode, etc?

sure, I assumed that part

> 
> > - simplify frontend: right now there's too much logical weight in the
> > frontends (yours and mine) which should be in the backend, as it's
> > supposed to know about the system
> >
> 
> wich kind of logic do you mean, I don't see too much logical weigh in my 
> frontend, I symply call the backend, read the xml output, parse it and fill 
> the GUI widgets when loading. When saving I validate all the info, generate 
> the xml output and then call the backend and pass the xml to it.

read above, doing that roundtrip for asking the interface type is
crappy, and assuming "ethX" for ethernet cards is simply wrong

the same applies for the wi-fi cards detection

	Hope that it's sensible enough for you :)

		Carlos

[1] see the "get_interface_name" directive in the network backend code

> 
> Cheers,