Browse openbeosnetteam: This Month's Archive • Main Archive Page • Related posts • Previous by Date • Next by Date

[openbeosnetteam] Re: Fwd: NetKit API prototype...

From: "David Reid" <dreid@xxxxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Date: Tue, 12 Mar 2002 13:01:21 -0000

> >> If it's about BNet* classes implementation, that's great,
> >> because half *client-side* library would be done, more or
> >> less (the second half is BIND functions -gethostbyname(),
> >> etc)
> >
> > Duh? Not quite sure but the code I looked at didn't really
> > do anything...
>
> I must disagree here :-)

You're allowed :)

> On the client side, the libnet.so is expected to export socket calls,
> BNet* classes and BIND calls.
> The real job behind the first two are not in the library herself, but
> should be handled by the network stack, via the /dev/net/stack driver.

:) I will -1 an attempt to add BIND code into our lib???.so as it's a
seperate library and belongs as such. Just a warning.

> What's don't do anything now is the /dev/net/stack driver, I agree on
that,
> and the link between him and the network stack, aka net_server is why
there
> nothing behind a socket() call. Yet.

Well, not quite true, but then have you reac the code in place already?

> With the addition of implemented (over BSD socket calls, that's right)
> BNet* classes, I think we'll have half of the libnet.so code implemented.
> Maybe not half but around 1/3, as BIND calls involves ready/parsing some
> /etc/services, /etc/resolv.conf, /etc/hosts files too, but anyway...

See my comment above. Oh, and try to look at a unix system as the only real
file that's directly associated with bind is /etc/resolv.conf, the others
are more general networking configuration files...

> I repeat: the "libnet.so library". Nor the network stack, nor the net_kit.
> Only libnet.so. One step by step...

Well, we won't have one library, we'll have one for C and one for c++, so
having one depend on the other is *BOGUS* and again I will -1 attempts to
drive it down that line.  Again, libnet.so == BSD sockets api, libnetapi.so
== C++ Be API, they should never meet.

> > I think we should remove binary files. They are a PITA to maintain and
> > caused a fair bit of trouble when using them for GTK...
>
> Agreed.
> Give me time to learn jamfiles, or better a jamfile sample :-)

OK. FWIW, I've broken your .proj as it is though by moving the headers...

> > The way I see it is that the CPP classes are just wrappers to the net
stack
> > in a different way to the BSD api.
>
> Correct. Like in R5.
>
> > I really don't think we should be layering things so heavily.
> > Basically where a C app would call socket(), a c++ app woudl call new
> > BNetEndpoint(), but the magic underneath is essentially the same, so
they
> > should be at the same level and I guess the C++ lib will use ioctl's and
so
> > on just like the C library...  Am I wrong?
>
> No.
> But if the ioctl's protocol evolve in the future (and it will!) we'll have
to
> upgrade the code both in socket() & co code *and* in C++ API code.

So? Don't see the issue here. If we change the way we talk to the server we
change the libs - wow - what a radical proposition!

> I don't think the extra-layering over sockets BSD add a performance hit.
Nothing compare to the userland <-> kernelland switching, at least.

It's *BOGUS* as if I'm writing a c++ app and want to talk to the server
using C++, why should I have to worry about a C library being loaded with
all the complications it can cause? No need for it really...

> Anyway, nothing to worry right now.

Whatever. Are we going to argue over this or are we going to try and find a
solution to the real issues we have?

david

References:

[openbeosnetteam] Re: Fwd: NetKit API prototype...
From: philippe . houdoin

[openbeosnetteam] Re: Fwd: NetKit API prototype...

Other related posts: