Re: Re: BeOS and IPC - try 999

Okay, I think the concept might revolve around idea of having some sort of
'libipc' for BEOS that created the map'ngs to Unix equivalents ... then
you could take any Unix based program that used IPC and compile it just by
adding -lipc to it ... its even a test we could easily add to our
configure checks ...

... but, personally, I think I've lost the whole point of this ... we do
the whole dynloader stuff based on 'a different *file* per operating
system' and its worked quite well ... what is the big issue about having
a 'unix_ipc.c', 'beos_ipc.c' and 'win_ipc.c' (if needed) and usin
whichever one as appropriate? It would be a simple configure check ...

Would it break something that I'm overlooking? As long as the Unix
developers are properly maintaining the unix_ipc.c variant, and someone
from the BEOS world (David, say) was maintaining the beos_ipc.c, who
cares?

David, I think that a BEOS libipc_unix.a, or something like that, that
could be link'd against for IPC emulation would be cool, and might make
porting those 10 other apps you've done easier ...

... but, if time isn't something you have much of, could you send me a
*clean* patch against the current source tree to look over? I think this
whole discussion has gotten way out of proportion and everyone is getting
frustrated ...

On Fri, 16 Jun 2000, David Reid wrote:

> > etc. That way there's essentially zero maintenance overhead for both the
> > Unix and the Beos factions. And you'd be doing yourself and the world a
> > big favour when you're trying to port the next IPC heavy program.
>
> OK. I've ported about 10 apps to BeOS and have done a lot of work on code
> for multi-platform interfaces and most have had IPC of some description or
> other - none have required writing an IPC emulation library!!! Why do you
> think it'll be zero maintenance? Sorry that argument goes way over my
> head... I mean if I write enough of an IPC emulation so it works today and
> you change the code to add a feature I haven't put in, it's broken isn't it?
> Maybe if I had unlimited time then I could write the library with every
> single function it could ever need, but practise shows that's unlikely.
>
> semctl and friends isn't the be all and end all. Wrapping it can be done,
> but as the beos code is far simpler, why? Tom said he wanted a way that
> "other non-unix" platforms could hook into pgsql. Having to write wrappers
> for unix api's isn't it going to help that.
>
> I dislike the wrapper approach as it provides a false level of comfort. I'm
> a firm believer that when you port, the best way is to have the code for the
> platform in the cleanest form possible and that's what I thought this patch
> achieved.
>
> If the criteria for getting code into your tree is that it "looks like what
> we use" then I guess I can accept that, but why didn't you say sooner? I
> guess when I get time I'll maybe look at it again but I have other things to
> do that people seem to appreciate and want. Sorry to be negative, but
> that's how I feel. :(
>
> david
>
> >
> >
> > --
> > Peter Eisentraut Sernanders vg 10:115
> > peter_e(at)gmx(dot)net 75262 Uppsala
> > http://yi.org/peter-e/ Sweden
> >
> >
>

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org