Lee Kindness wrote:
>
> mlw writes:
> > [ snip ]
> > Port lib. Regardless where it comes from, the porting code should be a self
> > contained library, not a list of objects. On Windows, a .DLL can do some things
> > easier than an application. Also, having a library allows more flexibility as
> > to how a port is designed.
> >
> > We should spec out our port interface. This includes file, semaphores, shared
> > memory, signals/events, process control, IPC, system resources, etc. This will
> > grow as we re-port to other environments like Windows.
>
> In other words ignore the POSIX capabilities/features of the largely
> compatible Unix systems and invent a layer over them to aid porting to
> more POSIXly challenged systems (i.e. Windows)...
>
> Seems like the wrong way of doing things - change the majority to aid
> the minority! Doesn't the current method of relying on POSIX
> compatability layers on Windows make more sense?
Depends, do you want the Windows version to actually be used? I have been
writing software for over 20 years now, and sometimes you just have to hold
your nose. It would be nice if we could code what we want, the way we want, in
the language we want, on the platforms we want.
Windows represents a HUGE user base, it also represents a platform for which a
real good native PostgreSQL should do well. There are, to my knowledge, no good
and free databases available for Windows.
PostgreSQL on Windows could be very cool as a serious poster child for why
open-source is the way to go.
>
> Even if such a 'port library' was the way forward, it should be just
> using an existing one, i.e. Apache [A]PR. No use replicating all the
> effort!
Absolutely, I think Apache's APR is pretty good.
