FreeLists / openbeosnetteam / [openbeosnetteam] Re: Me as well...

["David Reid" <dreid@xxxxxxxxxxxx>]

OK, so I guess the next thing we *really* need is for someone (not I) to
start tracking and creating a document detailing our desires/comments so
that we have somewhere to look for where we head next.

> > I don't think we should be aiming to create BONE or network_server. I
think
> > we should feel free and unburdened by the past (or convention) to go
forth
> > and create something new that works and performs. That is after all the
> > beos way is it not?
>
>
> Agreed; but we should not repeat the mistakes
> which already have been made by other people (All
> user-space network stack for example).

Exactly.  that would be a big mistake.  The big problem we'll have is
getting the balance between kernel and userland correct.  The other thing we
need to remember is that I'd expect the kernel to be in straight C, whereas
the userland libraries can be a mixture of c/c++.  I'd rather see straight C
being used and then a c++ wrapper added on top to give the higher level
functionality, but I'd like to think we would aim for an all C "lowest
level" solution. Why?  There are more people who know C and debugging is
generally more straightforward.  Also, it's harder to do stupid stuff in C++
:)  This also gets us what we want, which is a posix/bsd type set of
libraries and then a c++ set for those who want to write c++ code for their
beos only projects.

> > I realise a list of binaries isn't an item high on the list of
priorities,
> > but often it's important to flesh out a project fully before trying to
draw
> > the boundries and the requirements, wouldn't you agree?  As long as
people
> > feel free to contribute at the moment and say whatever they feel
hopefully
> > we won't have too many "damn, we missed this" type events :)
>
>
> I will certainly agree with this. What I meant was
> that if we have a stack that is designed with
> Posix- and bsd-compatibility in mind we should not
> have problems (maybe significant problems would be
> better ;-)) porting applications, and therefore
> the list of application should interpreted as a
> test case for compatibility. In other words most
> application like ssh, dig, etc. should compile
> "out of the box" (or at least network part should
> not cause any problems).

OK, yes I'll agree 100% with this :)  However, I do believe that the list of
apps also goes towards defining our end goal.  I'd like to be able say as we
start "we aim to provide a set of libraries, all these apps, these daemons
and blah de blah blah" if you get my meaning.  I'm not suggesting they'll be
hard, just that by having a reasonably defined end goal we have a better
chance of attaining it :)

> > I'd like to think that having posix compatibility would be high on
> > everyones list of priorities, as really the best understood networking
code
> > is that using the BSD interfaces, and if we are to have a hope of
getting a
> > truly useful network stack we need to be able to test and know the
results
> > we expect. Also this makes moving code over much easier.
> >
> > We'd all like more native apps, but the fact is that if we allow people
to
> > reuse unix-type sockets/network code then the developer can concentrate
far
> > more on getting the interface and the usability right - which has to be
> > good news.  We've been blessed with a very good set of highly usable
apps
> > for beos, let's see if we can't help that trend continue and grow :)
>
>
> I think we are trying to say the same thing...

Excellent!!

> > Man, do I go on at times :)
>
>
> :-D That was good, though.

Thanks. I have managed to sleep for 2 hours - though getting up was a PITA!

david