www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ODBC component licenses

reply Steve Teale <steve.teale britseyeview.com> writes:
The libraries for unixODBC and for FreeTDS (communication with SQL 
Server) are LGPL.

Would a D ODBC driver that used these be compatible with Phobos?

Steve
Nov 09 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale  
<steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?
glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you are saying what I think you are saying, yes. As long as the LGPL code is kept in a *separate* shared object, it is perfectly legal to link with it without infecting phobos' license. -Steve
Nov 10 2011
next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 10 Nov 2011 08:23:47 -0500, Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 <steve.teale britseyeview.com> wrote:
 
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?
glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you are saying what I think you are saying, yes. As long as the LGPL code is kept in a *separate* shared object, it is perfectly legal to link with it without infecting phobos' license. -Steve
I had wondered about the C library and how we got away with that. I think that we can find a sql.h and sqlext.h to convert, so it sounds like we should be good. I was thinking for a moment that we might have to go protocol level to speak to SQL Server. Steve
Nov 10 2011
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.
 
 Would a D ODBC driver that used these be compatible with Phobos?
glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you are saying what I think you are saying, yes. As long as the LGPL code is kept in a *separate* shared object, it is perfectly legal to link with it without infecting phobos' license.
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared object. So, if he's looking to put it _in_ Phobos, then I don't think that we can do that with the current setup. - Jonathan M Davis
Nov 10 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?
glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you are saying what I think you are saying, yes. As long as the LGPL code is kept in a *separate* shared object, it is perfectly legal to link with it without infecting phobos' license.
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared object. So, if he's looking to put it _in_ Phobos, then I don't think that we can do that with the current setup.
My understanding is that the FreeTDS is its *own* shared object (installed separately). We cannot include LGPL code in phobos.lib. BTW, phobos is not a shared object (yet). -Steve
Nov 10 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:
 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.
 
 Would a D ODBC driver that used these be compatible with Phobos?
glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you are saying what I think you are saying, yes. As long as the LGPL code is kept in a *separate* shared object, it is perfectly legal to link with it without infecting phobos' license.
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared object. So, if he's looking to put it _in_ Phobos, then I don't think that we can do that with the current setup.
My understanding is that the FreeTDS is its *own* shared object (installed separately). We cannot include LGPL code in phobos.lib.
I'm afraid that I've never even heard of TDS, so I'm not quite sure how that relates. We theoretically _could_ provide LGPL code in a separate library, but we don't do anything like that now.
 BTW, phobos is not a shared object (yet).
LOL. True. I didn't think that statement through enough. It's a library, but not a shared one. - Jonathan M Davis
Nov 10 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 13:36:38 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis  
 <jmdavisProg gmx.com>

 wrote:
 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?
glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you
are
 saying what I think you are saying, yes. As long as the LGPL code is
 kept
 in a *separate* shared object, it is perfectly legal to link with it
 without infecting phobos' license.
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared
object.
 So, if
 he's looking to put it _in_ Phobos, then I don't think that we can do
 that
 with the current setup.
My understanding is that the FreeTDS is its *own* shared object (installed separately). We cannot include LGPL code in phobos.lib.
I'm afraid that I've never even heard of TDS, so I'm not quite sure how that relates. We theoretically _could_ provide LGPL code in a separate library, but we don't do anything like that now.
I wasn't sure so I looked it up: http://www.freetds.org/faq.html#where.is.libtds.so Apparently, you can still have LGPL code that is statically linked? I'm not sure now how that works, my understanding was always that LGPL works because of shared objects. -Steve
Nov 10 2011
parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 10 Nov 2011 13:54:04 -0500, Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 13:36:38 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:
 
 On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>

 wrote:
 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with
 SQL Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?
glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you
are
 saying what I think you are saying, yes. As long as the LGPL code
 is kept
 in a *separate* shared object, it is perfectly legal to link with
 it without infecting phobos' license.
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared
object.
 So, if
 he's looking to put it _in_ Phobos, then I don't think that we can
 do that
 with the current setup.
My understanding is that the FreeTDS is its *own* shared object (installed separately). We cannot include LGPL code in phobos.lib.
I'm afraid that I've never even heard of TDS, so I'm not quite sure how that relates. We theoretically _could_ provide LGPL code in a separate library, but we don't do anything like that now.
I wasn't sure so I looked it up: http://www.freetds.org/faq.html#where.is.libtds.so Apparently, you can still have LGPL code that is statically linked? I'm not sure now how that works, my understanding was always that LGPL works because of shared objects. -Steve
I've just done my first thing in the morning thing again with Pan and deleted one of your postings in the thread. So lots of things can't be included in Phobos because it is one big static library, right? If you don't include some Phobos module in your app, the linker still wants to pull in the unsatisfied externals for that module even though they will not be used? I thought that a library was an archive, and that linkers just pulled in the object files that were required by the app. If that's not the case, then having D able to easily generate DLLs and shared libraries would seem to be priority number one. Clearly we don't have any philosophical objection to using external libraries from Phobos - std.socket points out that you have to link with the Windows sockets library. Or is that one of the old libraries that Microsoft lets Walter use? Steve
Nov 10 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-11-11 05:25, Steve Teale wrote:

 I've just done my first thing in the morning thing again with Pan and
 deleted one of your postings in the thread.

 So lots of things can't be included in Phobos because it is one big
 static library, right?

 If you don't include some Phobos module in your app, the linker still
 wants to pull in the unsatisfied externals for that module even though
 they will not be used?
No, it won't. Tango uses external libraries, libz and libssl. You have to explicitly link those libraries when you use those modules, but only for those modules and no other modules.
 I thought that a library was an archive, and that linkers just pulled in
 the object files that were required by the app.

 If that's not the case, then having D able to easily generate DLLs and
 shared libraries would seem to be priority number one.

 Clearly we don't have any philosophical objection to using external
 libraries from Phobos - std.socket points out that you have to link with
 the Windows sockets library. Or is that one of the old libraries that
 Microsoft lets Walter use?

 Steve
-- /Jacob Carlborg
Nov 10 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 23:25:38 -0500, Steve Teale  
<steve.teale britseyeview.com> wrote:

 On Thu, 10 Nov 2011 13:54:04 -0500, Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 13:36:38 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:

 On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>

 wrote:
 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with
 SQL Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?
glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you
are
 saying what I think you are saying, yes. As long as the LGPL code
 is kept
 in a *separate* shared object, it is perfectly legal to link with
 it without infecting phobos' license.
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared
object.
 So, if
 he's looking to put it _in_ Phobos, then I don't think that we can
 do that
 with the current setup.
My understanding is that the FreeTDS is its *own* shared object (installed separately). We cannot include LGPL code in phobos.lib.
I'm afraid that I've never even heard of TDS, so I'm not quite sure how that relates. We theoretically _could_ provide LGPL code in a separate library, but we don't do anything like that now.
I wasn't sure so I looked it up: http://www.freetds.org/faq.html#where.is.libtds.so Apparently, you can still have LGPL code that is statically linked? I'm not sure now how that works, my understanding was always that LGPL works because of shared objects. -Steve
I've just done my first thing in the morning thing again with Pan and deleted one of your postings in the thread.
opera :) You can always use webnews to look for posts that you accidentally deleted: http://www.digitalmars.com/webnews/newsgroups.php Or use the archive (from digitalmars.com website), but this seems to lag the actual posts by some period of time.
 So lots of things can't be included in Phobos because it is one big
 static library, right?
I don't know. When I said I'm not sure, it wasn't a euphemism for thinking it wouldn't work, I literally am not sure. Maybe it can be done, but the licensing issues have to be worked out, even if it doesn't taint the rest of phobos. Clearly if someone is to ship a program which uses libfreetds.a, they would need to provide source code for the library. Is this something we want to require users of phobos + SQL server to do? I don't know. I'm just very surprised they use static libs (and it looks from that post like a recent change).
 If you don't include some Phobos module in your app, the linker still
 wants to pull in the unsatisfied externals for that module even though
 they will not be used?
There are some technical issues. For example, if phobos depends on a library, then that library has to come *after* phobos. In a recent update to ubuntu, the link order became very important, and it broke all dmd versions that had std.datetime, because it requires the librt.so library. Therefore the link line had to be -lphobos -lrt in that order. However, dmd *always* tacks on -lphobos at the end of the link line, regardless of what is in configuration or command line. However, certain libraries phobos depends on are added after -lphobos, such as -lm and -lpthread. Walter fixed the problem for 2.056 by tacking on -lrt as well. This solution could *not* be used for freetds because it's not a default install in any modern OS (seeing as how it's a static lib, it would only be installed if you were interested in developing with it). Even though the linker will probably ignore the lib if you don't use any symbols from it, I don't think it will work if it can't *find* the lib. However, if phobos' database API is an extendable *framework*, then one could define 3rd party libs that add non-compatible licensed code to be used when needed. It's far from an ideal situation, but licensing is a real issue that must be worked around. I'll add that I am not a lawyer and I'm not 100% positive of the path we need to take.
 If that's not the case, then having D able to easily generate DLLs and
 shared libraries would seem to be priority number one.
I have felt this for a long time. As long as dmd cannot easily generate native DLLs, it will be a toy language.
 Clearly we don't have any philosophical objection to using external
 libraries from Phobos - std.socket points out that you have to link with
 the Windows sockets library. Or is that one of the old libraries that
 Microsoft lets Walter use?
First, that is an OS-provided library that is not GPL'd or LGPL'd. You are free to use it in whatever code you wish, and it is *always* installed on every windows OS (starting with windows 98 I think?) Second, you may be confused by the linking process on Windows. WS2_32.lib is *not* a static library, it's a linker file. In windows, you need this linker file in order to link against a DLL. -Steve
Nov 11 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-11-10 19:36, Jonathan M Davis wrote:
 I'm afraid that I've never even heard of TDS, so I'm not quite sure how that
 relates. We theoretically _could_ provide LGPL code in a separate library, but
 we don't do anything like that now.
TDS - Tabular Data Stream, is the protocol Microsoft uses for SQL Server, also used by Sybase. FreeTDS would be the free implementation of that protocol and it uses the LGPL license. ODBC is a database independent layer. When ODBC connects to SQL Server it uses the FreeTDS library. It's not necessary to use ODBC to connect to SQL Server, FreeTDS can be used on its own (don't know how low level FreeTDS actually is). I would recommend creating bindings to FreeTDS for connecting to SQL Server. Of curse, an ODBC driver would be good to have as well.
 BTW, phobos is not a shared object (yet).
LOL. True. I didn't think that statement through enough. It's a library, but not a shared one. - Jonathan M Davis
-- /Jacob Carlborg
Nov 10 2011
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis wrote:

 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared object. So, if he's looking to put it _in_ Phobos, then I don't think that we can do that with the current setup. - Jonathan M Davis
So what about etc.curl for instance? Steve
Nov 10 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 19:13:00 Steve Teale wrote:
 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis wrote:
 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared object. So, if he's looking to put it _in_ Phobos, then I don't think that we can do that with the current setup. - Jonathan M Davis
So what about etc.curl for instance?
It's not LGPL. - Jonathan M Davis
Nov 10 2011
parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 10 Nov 2011 12:39:28 -0800, Jonathan M Davis wrote:

 On Thursday, November 10, 2011 19:13:00 Steve Teale wrote:
 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis wrote:
 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared object. So, if he's looking to put it _in_ Phobos, then I don't think that we can do that with the current setup. - Jonathan M Davis
So what about etc.curl for instance?
 It's not LGPL.
Steve thought linking to LGPL was not a problem - we link to glibc But it presumably has to be linked to a library? Steve
Nov 10 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 23:01:57 -0500, Steve Teale  
<steve.teale britseyeview.com> wrote:

 On Thu, 10 Nov 2011 12:39:28 -0800, Jonathan M Davis wrote:

 On Thursday, November 10, 2011 19:13:00 Steve Teale wrote:
 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis wrote:
 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
Though the fact that it needs to be in a separate shared object does make it problematic to stick in Phobos, since Phobos is just one shared object. So, if he's looking to put it _in_ Phobos, then I don't think that we can do that with the current setup. - Jonathan M Davis
So what about etc.curl for instance?
 It's not LGPL.
Steve thought linking to LGPL was not a problem - we link to glibc But it presumably has to be linked to a library?
I'm 100% sure linking to an LGPL shared object is fine for Phobos. I'm not sure at all linking to an LGPL static library is fine for Phobos. There are both legal and philosophical issues to resolve. From what I've read online, it appears to be legal with certain versions of the LGPL, maybe all of them. BTW, I started reading this post thinking you were referring to yourself in the 3rd person :) -Steve
Nov 11 2011
prev sibling parent reply Dejan Lekic <dejan.lekic tiscali.co.uk> writes:
On 10/11/11 05:55, Steve Teale wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?

 Steve
I would strongly advice any DB driver go into a separate library instead of Phobos. Too many unneeded modules are in Phobos already and more modules that do not belong in Phobos are about to be accepted... Possibly all DB drivers could go into one, or separate (better, so one can load them when needed) libraries. If that is the case, the author can use any license he or she likes. Kind regards
Nov 10 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 19:50:03 Dejan Lekic wrote:
 On 10/11/11 05:55, Steve Teale wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.
 
 Would a D ODBC driver that used these be compatible with Phobos?
 
 Steve
I would strongly advice any DB driver go into a separate library instead of Phobos. Too many unneeded modules are in Phobos already and more modules that do not belong in Phobos are about to be accepted...
Like what?
 Possibly all DB drivers could go into one, or separate (better, so one
 can load them when needed) libraries. If that is the case, the author
 can use any license he or she likes.
It's going to have to be set up such that 3rd party DB drivers can be used, but the more of them that we can put in Phobos, the better, since it makes it easier to find and use them. The entire issue here is licensing, not whether we _want_ to stick it in Phobos. - Jonathan M Davis
Nov 10 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/10/11 1:50 PM, Dejan Lekic wrote:
 On 10/11/11 05:55, Steve Teale wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?

 Steve
I would strongly advice any DB driver go into a separate library instead of Phobos. Too many unneeded modules are in Phobos already and more modules that do not belong in Phobos are about to be accepted...
I thought the main concern was that there's too little stuff in Phobos, and that growth is good. Seems like whatever we do we won't please everyone. Andrei
Nov 10 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 16:06:56 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 11/10/11 1:50 PM, Dejan Lekic wrote:
 On 10/11/11 05:55, Steve Teale wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?

 Steve
I would strongly advice any DB driver go into a separate library instead of Phobos. Too many unneeded modules are in Phobos already and more modules that do not belong in Phobos are about to be accepted...
I thought the main concern was that there's too little stuff in Phobos, and that growth is good. Seems like whatever we do we won't please everyone.
Well, one concern I would have is making *phobos* dependent on these libraries, which may not be needed (or installed). Note that in recent times, dmd failed to compile any programs Ubuntu because of new linking rules. The solution was to add -lrt to the dmd source code that generates the link line. Is that the same solution for FreeTDS? What if FreeTDS isn't installed (it typically is not)? What if you don't use the database system, why should you have to link against FreeTDS if it's not being used? I'd much rather have the database subsystem *framework* be a part of phobos, and the actual implementations be defined as 3rd party libs. Just from a practical point of view. -Steve
Nov 10 2011
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 13:49 Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 16:06:56 -0500, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:
 On 11/10/11 1:50 PM, Dejan Lekic wrote:
 On 10/11/11 05:55, Steve Teale wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.
 
 Would a D ODBC driver that used these be compatible with Phobos?
 
 Steve
I would strongly advice any DB driver go into a separate library instead of Phobos. Too many unneeded modules are in Phobos already and more modules that do not belong in Phobos are about to be accepted...
I thought the main concern was that there's too little stuff in Phobos, and that growth is good. Seems like whatever we do we won't please everyone.
Well, one concern I would have is making *phobos* dependent on these libraries, which may not be needed (or installed). Note that in recent times, dmd failed to compile any programs Ubuntu because of new linking rules. The solution was to add -lrt to the dmd source code that generates the link line. Is that the same solution for FreeTDS? What if FreeTDS isn't installed (it typically is not)? What if you don't use the database system, why should you have to link against FreeTDS if it's not being used? I'd much rather have the database subsystem *framework* be a part of phobos, and the actual implementations be defined as 3rd party libs. Just from a practical point of view.
Yeah. Adding functionality to Phobos which is pure D is generally a good thing (though stuff which really isn't generally useful obviously shouldn't be in there). But adding stuff that requires additional dependencies is far more iffy. If the module is really self-contained and you can get away with using Phobos without linking in the library that it needs as long as you don't use it, then it's not necessarily a big deal. But if it's going to require that everyone using Phobos link it in and it's not standard on all systems, then it needs a really solid reason for being in Phobos. And if we get in a situation where we need to add extra linking commands to dmd itself (as we had to with librt) for each such library, then that becomes undesirable very quickly IMHO. And given the licensing issues that we're seeing with the DB stuff, that lends even more credence to the idea of just having them all as separate modules with just the framework being in Phobos. It would be nice to have them in Phobos, but if we're going to have licensing problems and/or dependency problems because it, then they shouldn't be in Phobos proper. - Jonathan M Davis
Nov 10 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-10 23:24, Jonathan M Davis wrote:

 Yeah. Adding functionality to Phobos which is pure D is generally a good thing
 (though stuff which really isn't generally useful obviously shouldn't be in
 there). But adding stuff that requires additional dependencies is far more
 iffy. If the module is really self-contained and you can get away with using
 Phobos without linking in the library that it needs as long as you don't use
 it, then it's not necessarily a big deal. But if it's going to require that
 everyone using Phobos link it in and it's not standard on all systems, then it
 needs a really solid reason for being in Phobos. And if we get in a situation
 where we need to add extra linking commands to dmd itself (as we had to with
 librt) for each such library, then that becomes undesirable very quickly IMHO.
If dlopen is used to load a dynamic library then there shouldn't be any problem. It will be automatically loaded and only when needed. -- /Jacob Carlborg
Nov 11 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 Nov 2011 05:49:32 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2011-11-10 23:24, Jonathan M Davis wrote:

 Yeah. Adding functionality to Phobos which is pure D is generally a  
 good thing
 (though stuff which really isn't generally useful obviously shouldn't  
 be in
 there). But adding stuff that requires additional dependencies is far  
 more
 iffy. If the module is really self-contained and you can get away with  
 using
 Phobos without linking in the library that it needs as long as you  
 don't use
 it, then it's not necessarily a big deal. But if it's going to require  
 that
 everyone using Phobos link it in and it's not standard on all systems,  
 then it
 needs a really solid reason for being in Phobos. And if we get in a  
 situation
 where we need to add extra linking commands to dmd itself (as we had to  
 with
 librt) for each such library, then that becomes undesirable very  
 quickly IMHO.
If dlopen is used to load a dynamic library then there shouldn't be any problem. It will be automatically loaded and only when needed.
The subject of this discussion (FreeTDS) apparently only comes in static library form (unless we want to build and support dynamic libraries of it). -Steve
Nov 11 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-11 14:06, Steven Schveighoffer wrote:
 On Fri, 11 Nov 2011 05:49:32 -0500, Jacob Carlborg <doob me.com> wrote:
 If dlopen is used to load a dynamic library then there shouldn't be
 any problem. It will be automatically loaded and only when needed.
The subject of this discussion (FreeTDS) apparently only comes in static library form (unless we want to build and support dynamic libraries of it). -Steve
Hmm, I have FreeTDS installed as a dynamic library and I'm using it via Ruby on Rails. But I can see on the freetds FAQ page that it doesn't provide a dynamic library any more. I didn't know about that. It seems one should have some kind of client library, which I assume can be a dynamic library. -- /Jacob Carlborg
Nov 11 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 Nov 2011 10:32:00 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2011-11-11 14:06, Steven Schveighoffer wrote:
 On Fri, 11 Nov 2011 05:49:32 -0500, Jacob Carlborg <doob me.com> wrote:
 If dlopen is used to load a dynamic library then there shouldn't be
 any problem. It will be automatically loaded and only when needed.
The subject of this discussion (FreeTDS) apparently only comes in static library form (unless we want to build and support dynamic libraries of it). -Steve
Hmm, I have FreeTDS installed as a dynamic library and I'm using it via Ruby on Rails. But I can see on the freetds FAQ page that it doesn't provide a dynamic library any more. I didn't know about that. It seems one should have some kind of client library, which I assume can be a dynamic library.
I think the approach we should support is defining a framework in phobos, and then implementations in external libs. These external libs don't have to be dynamic ones. -Steve
Nov 11 2011
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
 The subject of this discussion (FreeTDS) apparently only comes in static
 library form (unless we want to build and support dynamic libraries of
 it).
 
 -Steve
Well, the one I downloaded a couple of days ago is a .so, and I'm not linking to that anyway, but to libodbc.so (part of unixODBC). The FreeTDS lib must be dynamically loaded by unixODBC, so given that the two are like hand in glove, it's difficult to see how they would change it to a .a.
Nov 11 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 Nov 2011 13:41:45 -0500, Steve Teale  
<steve.teale britseyeview.com> wrote:

 The subject of this discussion (FreeTDS) apparently only comes in static
 library form (unless we want to build and support dynamic libraries of
 it).

 -Steve
Well, the one I downloaded a couple of days ago is a .so, and I'm not linking to that anyway, but to libodbc.so (part of unixODBC). The FreeTDS lib must be dynamically loaded by unixODBC, so given that the two are like hand in glove, it's difficult to see how they would change it to a .a.
If it's a .so, and you are using a wrapper library, I think it should be fine license-wise. But there is still the issue of making phobos dependent on a not-so-common lib (not everyone has unixODBC installed on their system). -Steve
Nov 11 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-10 22:49, Steven Schveighoffer wrote:
 On Thu, 10 Nov 2011 16:06:56 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 11/10/11 1:50 PM, Dejan Lekic wrote:
 On 10/11/11 05:55, Steve Teale wrote:
 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?

 Steve
I would strongly advice any DB driver go into a separate library instead of Phobos. Too many unneeded modules are in Phobos already and more modules that do not belong in Phobos are about to be accepted...
I thought the main concern was that there's too little stuff in Phobos, and that growth is good. Seems like whatever we do we won't please everyone.
Well, one concern I would have is making *phobos* dependent on these libraries, which may not be needed (or installed). Note that in recent times, dmd failed to compile any programs Ubuntu because of new linking rules. The solution was to add -lrt to the dmd source code that generates the link line. Is that the same solution for FreeTDS? What if FreeTDS isn't installed (it typically is not)? What if you don't use the database system, why should you have to link against FreeTDS if it's not being used? I'd much rather have the database subsystem *framework* be a part of phobos, and the actual implementations be defined as 3rd party libs. Just from a practical point of view. -Steve
With Tango you need to explicitly link to the third party libraries it uses, like libz and libssl. -- /Jacob Carlborg
Nov 10 2011
next sibling parent Jude Young <10equals2 gmail.com> writes:
 I'd much rather have the database subsystem *framework* be a part of
 phobos, and the actual implementations be defined as 3rd party libs.
 Just from a practical point of view.
Wait, wasn't that the point of CAPI/Deimos? It seems that there is a bit of overlap here....
Nov 10 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 11, 2011 01:41:12 Jude Young wrote:
 I'd much rather have the database subsystem *framework* be a part of
 phobos, and the actual implementations be defined as 3rd party libs.
 Just from a practical point of view.
Wait, wasn't that the point of CAPI/Deimos? It seems that there is a bit of overlap here....
No. Deimos is for C headers which have been translated to D. What we're talking about here are modules which provide engines for Phobos' database framework. There will be modules for various databases - sqlite, postgres, etc. Those modules will be written in D using the API that the database framework requires, and they will _use_ C headers which were translated to D (possibly in Deimos), but they will not _be_ such headers, so they're not part of Deimos. Whether they will end up in Phobos proper or not will depend on stuff like what licenses they have. - Jonathan M Davis
Nov 10 2011
parent Steve Teale <steve.teale britseyeview.com> writes:
 No. Deimos is for C headers which have been translated to D. What we're
 talking about here are modules which provide engines for Phobos'
 database framework. There will be modules for various databases -
 sqlite, postgres, etc. Those modules will be written in D using the API
 that the database framework requires, and they will _use_ C headers
 which were translated to D (possibly in Deimos), but they will not _be_
 such headers, so they're not part of Deimos. Whether they will end up in
 Phobos proper or not will depend on stuff like what licenses they have.
 
 - Jonathan M Davis
Jonathan, Agreed, that's how I understand the situation, but it seems to be increasingly clear that this is not sufficient. If there are to be easy to use D components, Deimos should be a two-level thing, with the translated headers in the lower layer, and the sort of stuff we've been talking about in an upper layer. The alternative for the database stuff is to do everything where there is a licensing issue at protocol level. I think this is the way PHP has gone. If I bit the bullet and did TDS, we'd be able to cover MySQL (protocol), Postgres (I'm assuming their license is sufficiently liberal), SQLite (no license), SQL Server (protocol), and SyBase (protocol). At that point we could probably relax. Oracle, DB2, and whoever would probably contribute components in time. This is making my head hurt, especially taken with a dose of trying to do a decent translation of ODBC header files to D! Steve
Nov 11 2011