[openbeosnetteam] Re: DHCP Client needed,what would stand in theway?
From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
To: openbeosnetteam@xxxxxxxxxxxxx
Date: Tue, 29 Jul 2003 02:19:05 +0200 CEST
"Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote:
> Sorry that it took so long, but I had some code to commit. ;)
No problem, I am not in a hurry... :)
> > What do you mean with this? driver_settings can be written
> > manually,
> > they can be programmatically edited, and written back to a file
> > easily
> > with the new API extensions.
> So, is the extended driver settings API finished (that one listed on
> the
> kernel team task list)?
The API is almost finished - expect something to overlay an existing
settings structure with new data is missing right now. That would not
only be needed by the settings idea I proposed, but also by the boot
loader which, at least in R5, allows to add new settings in the boot
process.
> Or do you plan to extended it to support flattening BMessages in
> driver_setttings format?
No, definitely not (yet). That would require many changes in the
format, and I am afraid they wouldn't be that nice. That's something to
think about at a later time, though.
It would be easy if there would be only strings in those BMessages,
though :-)
> > BTW I guess I will have to write a newsletter article about the
> > revised
> > driver_settings API anyway.
> Please do. :)
Sure :)
> > If there are more than one file per profile, we should just put
> > them
> > all into one directory per profile.
> > Also, (independently from the directory/file structure) we could do
> > neat things like have a basic profile that others will inherit if
> > specifications are missing.
> The copy-paste method is a very good alternative. ;)
Copy-paste?
> > So we could have a whole basic configuration and the profiles will
> > just
> > change the IP address or switch DHCP on/off. I would be okay if
> > that
> > advanced feature would only be available through the command line
> > (at
> > first), though :)
> That is okay for me, too.
> GUI programming eats up too much time that we do not have.
And GUI programming is not so easy as it seems - it's actually hard to
get it right.
Adios...
Axel.
