[openbeosnetteam] Re: Design mess

Quoting Lars Hansson:

> > - run scripts/apps from kernel-land
>
> No, that's just bad design and opens up a way to large can-o-worms.

Well, pretty much all standards apps after BeOS startup are launch by the kernel
thru a script, I don't see how it's a bad design.
Launching them from kernel doesn't mean they have kernel/root privileges nor
they can do more than usual apps launched from userland!

Anyway, I'm not suggesting here that every stack component should launch and
etablish a permanent communication link with userland apps or scripts.
No, I'm just saying that instead of yet another *_server app that will be
sleeping most of the time until some stack component wake him to do some task 
like showing some windows, we could drop the *sleepy* server and launch such
window-showing small app directly from the component.

What do you like better, guys:
- a stack component use a semaphore to wakeup a userland "daemon"
- the daemon awake and run his add-ons (which one? Some extra info is needed
here, right?)
- the add-on do his task, like open a window

Or

- a stack component launch (from kernelland, indeed) an app, giving him some
arguments (like the current interface, the kind of event, etc)
- the app do his task, like open a window

Oh, well, maybe it's just me, sleeping daemons sounds too much evils to me.
;-)


> > Yes, of course. I don't like having dhcpd, inetd, pppd, etc. running in
> > background, either, and I want the stack to be self-contained.
>
> What's the problem with delegating distinctly different tasks to different
> programs?

Nothing. In fact, I'm advocating exactly the same by suggesting to drop a sleepy
server + add-ons in favor of several userland apps (eventually scripts) launched
(fire & forget) by stack components when user interaction/notification is
required.

We had the same debate about the ScreenSavers server which since was dropped in
favor of a simpler "screen_blanker" app fired by the input filter. No more
server that should be *always* running.
Except if everybody wants to move the network stack in userland, we should not
have a mandatory server just to show up some GUI when a dialup connection went
up or down, when a WAN is detected/lost, or whatever.
What we need is some apps doing these GUI tasks, launched by the stack
components.

> One program, or code blob, that does everything is usually bad
> design. It's not like the user has to be aware of them.

Our issue here is that our stack is mostly a "code blob" adapted from BSD TCP/IP
monolithic stack to a semi-modular design. We don't have many "distincly
different tasks", even if we tried to apply a modular design to each protocols
and interfaces.

So, sadly, we already have to deal with a... not good enough design. We choose
for R1 to postpone a potential refactoring of the stack design.

Please, BTW, notice that nobody released a better designed network stack in open
source so far. I think that's because network stacks implementation details are
often ugly, and it's hard to keep your design clean in such environment.
And it's not like I don't care a lot about cleaness...

Other related posts: