[openbeosnetteam] Re: Network preflet, the future?

  • From: Philippe Houdoin <philippe.houdoin@xxxxxxx>
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Thu, 18 Sep 2003 22:18:10 +0200

Niels Reedijk wrote:
> I've been playing with the new network preflet, 

Oh, so am I! ;-)
Okay, maybe I should have told you guys... :-\

Here some screenshots:
http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/network_gui-
01.png
http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/network_gui-
02.png
http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/network_gui-
03.png

I discuss them with Axel last monday, BTW.

> However, while I was working on this, 
> I realised
> not only the front end needs to be designed, but also the back end. 

Yep. Only the BIND part of libnet.so require, use and support external settings 
files (/etc/protocols, /etc/services and co...).
The current stack should be configure via ifconfig tool.

> There should be a main way of storing settings. I believe that normal 
> BMessages
> would suffice, however, a human readable (and editable) version perhaps 
> is a good
> idea as well. This, however, will mean that a whole new backend needs 
> to be
> designed, which, I'm sure, will be in R2, but not right now. I suggest 
> using a BMessage
> scheme. 

We have alreayd discuss that previously, looks from this thread post:
//www.freelists.org/archives/openbeosnetteam/07-2003/msg00083.html

In fact, using driver_settings.h settings file format will be far quicker:
- API to read them from kernelland is already there, even in R5
- Axel wrote the OBOS implementation of this API, and it's easy to use it even 
from userland now
- Writing this settings file format is really easy
- It's human readable and editable, if required (but not desired!)
- BMessage internal structures will evolve, and we don't have a kernel land 
implementation right now
- BMessage are not human readable and editable.

So, I stand by using several driver_settings syntax formatted settings files, 
stored under /etc/network/profiles/<profile_name>.
A default profile in /etc/network/profiles/default will contains all default 
settings, coming with the stack, and serve as fallback settings files if the 
active profile don't have one setting (file, or even one setting parameter).

Last but not least, the current profile is stored as 
a /etc/network/profiles/current relative symlink. Or default if none present.

> Furthermore, there should be a way to communicate these settings to the 
> kernel
> network modules. An option is that all the modules open the network 
> preferences,
> however, the kernel should learn BMessages then, and they should be 
> informed on
> what profile is loaded.

Except for the BMessage format, I agree here.
That would involve to write some helpers functions to do this mecanism that 
stack modules will call to get their settings.
From userland, a ioctl() opcode would allow to notify the stack to broadcast 
thru their modules that settings have changed.

> A better way would thus be to have an application start via the 
> Bootscript (or 
> something similar) that loads all the settings to the kernel modules 
> using 
> ioctl(...). It could be an application (let's just name it 'netconfig') 
> that puts the
> settings in the kernel, 

That's basicly the way our current stack is setup today: via ifconfig.
BONE do that in his /beos/boot/netscript, too.
I find this way too Unix-y, too init.d-y.

The current (or default if none) profile should be determined by the 
stack "settings" helpers functions, and the settings loads from them at each 
module request.
For example, interfaces modules may want to load 
from /etc/network/profiles/current/interfaces the settings 
from "/dev/net/tulip/0" section, "dhcp" option.

/dev/net/tulip/0 {
  dhcp on
  mtu  1492
  mode full-duplex
}

If this file don't exists, the helper function will try to get it 
from /etc/network/profiles/default/interfaces file.

> Anyway, back to the thing that all started these thoughts: the network 
> preflet. In
> the attached screenshot, you see the basis of the preflet: A window 
> with a general
> profile. The main theory of operation is that the application maintains 
> a list of
> profiles, acts as a settings loader/writer for the add-ins, and 
> provides the GUI facilities
> for each add-in

So far, agreed 100%

> to have its own status message (if needed, so the 
> ethernet module
> can add status messages for all the interfaces it controls). A standard 
> add-in, called
> the common_settings add-in will be added for controlling the main 
> stack, there'll
> also be an ethernet add-in, and a lovely ppp add-in. 

A stack status/overview add-on may offer the same feature without the need to 
tweak the preflet to know about it. Not all preflet add-on need to allow stack 
being setup by user. Why not a "About OBOS Network Kit team" add-on, aka credit 
add-on for example!?
;-) 

> Anyway, how does 
> the GUI work?

The profile managment (creation, deletion, etc) should not appear as another 
one settings *group*.
The real job of the preflet his exactly that: allow the user to manage settings 
profiles. It provide a graphical hosting for add-ons that do the real job, not 
necessarly related to settings.
He must offer a way to each add-ons to know when and in which location (aka 
profile subfolder) he should write his settings.

> (I know I'm not a GUI wizard, and I'm not referring to the actual look/
> spacing of the 
> preflet, but rather the place of the controlls, their descriptions, 
> etcetera). Will it
> suffice?

I will rather like to move the "restart the stack" button under a stack 
overview/status add-on than right in front user every time.
net_server syndrom, I know...

I'll zip my current preflet skeleton, so we can share it between us.

-Philippe

Other related posts:

  1. Home
  2. openbeosnetteam
  3. Archive
  4. 09-2003