Re: Specification of "/" in the host name (for Unix socket support)

On Sat, Sep 13, 2003 at 05:28:03PM +0100, Paul Thomas wrote:
> On 13/09/2003 00:53 Tom Lane wrote:
>
> >You got up on the wrong side of the bed today?  What's platform-specific
> >about Unix sockets?
>
> Well, Sun must regard them as pretty platform-specific as they're not part
> of the Java spec. In practice there's another issue. Its called binary
> compability. PostgreSQL users currently have the luxury of a type-4 (i.e.,
> pure Java) JDBC driver. So a driver can be built on a Linux box (for
> example) and that binary will also run on Windows, Solaris... Unix sockets
> would have to be accessed though JNI thus making the driver a type-3
> driver. Kiss goodbye to binary portability. And forget running the driver
> on Windows without (I would imagine) cygwin installed - and that would
> re-map to tcp/ip sockets "pretending" to be unix sockets - can't see much
> advantage in that one. Forget using JDBC from applets to as that requires
> a type-4 driver. Not that I would imagine that there are many people doing
> JDBC from applets but the ability is there ATM. That kind of portability I
> live without!

It's entirely possible to do support for unix sockets in a way that only
requires the JNI piece (and, in fact, most of the support classes) if you
actually *want* support for unix sockets. You need one layer of indirection
so that the generic code can deal in terms of a "PgSocket" interface always,
then just have different implementations that are loaded dynamically by name
based on the URL's scheme; if the load fails because of a
ClassNotFoundException or UnsatisfiedLinkError (because the AF_UNIX support
classes or JNI library are not available) you just don't support that URL
scheme.

So you can still distribute a generic type-4 driver with a note that says
"if you want AF_UNIX support, you need to make an implementation of these
classes available to the driver, e.g. by installing this piece of
JNI-supported code available at ..".

Would this satisfy your objections?

Actually, my real concern is this bit (from the GNU Classpath docs):

 Linking this library statically or dynamically with other modules is making
 a combined work based on this library. Thus, the terms and conditions of the
 GNU General Public License cover the whole combination.

This would seem to make it hard to build & distribute a version of the
driver that built against the AF_UNIX code that's "derived from GNU
classpath" without invoking the GPL on the whole driver, even with the sort
of indirection I described above. We'd need a generic interface for AF_UNIX
sockets to build against, where one implementation was the
GNU-classpath-derived code, plus a search mechanism etc .. basically
reproduce much of the framework that java.net provides for socket
implementations.

-O