> From: Dan McGrath > 1) By having to pay for something as elemental as > language bindings... > > 2) How do create a language binding for U2 without several issues...
Dan, I believe my notes were misunderstood. To your point #1: When I talk about someone paying for coding, I didn't mean language bindings would be a for-sale product. I thought all of the notes about this being a community project made that clear. I'm saying language bindings can be FOSS, but people shouldn't be asked to starve in the name of creating and supporting FOSS for the benefit of everyone else. To your point #2: I fully agree that "properly done", language bindings should come from the company, with proper security, etc. But we all know that won't happen. So here we are into yet another decade of Pick where we can either lament about all the things that should be done by the vendors, or we can do what we can and work with the constraints. When people create language bindings for a package like cURL, they don't talk about how inherently insecure protocols are. The point is that people need to use the protocols as they are with the languages they prefer. Let's get to that point, while still working with the DBMS vendors on better pipes and better security. These are separate initiatives. Let's not let every extension to the environment be left undone by "us" because there are some features not implemented by "them". For reference, the language binding interface that I've created exposes a single API for all MV platforms. This can be used by all languages with minor variation for syntax differences. By definition of the project, connectivity to the DBMS is abstracted within the components that implement the language-specific implementation. In other words, a given language binding itself defers DBMS connectivity to yet another layer of abstraction. This allows a single language binding to be connected to any MV database, using any available connectivity tool. This gives us permutations like: Ruby>UOJ>Universe PHP>UOJ>Unidata Haskell>jRCS>jBase Haskell>UOJ>Universe Eiffel>mv.NET>Reality Eiffel>QMClient>QM Lisp>mv.NET>mvBase Perl>QMClient>QM Perl>UOJ>Unidata Smalltalk>UO.NET>Universe All of this is intended to be free and open source so that all of us have the FREEdom to fix and enhance individual bindings for the greater good. In the name of performance, any language binding can support a more direct connection to any DBMS of choice, as long as the API exposed to client code doesn't change. Consumers of these bindings can then choose to use platform-independent bindings or platform-specific bindings. Most people here don't care about Reality or mvBase, don't care about QMClient or mv.NET, and don't care about Eiffel or Smalltalk. That's fine. Once the API is defined, different groups of people can focus on their preferred interfaces. But right now absoilutely none of the above interfaces exist for any MV platform. I'm hoping we can get from nothing to something, and it's entirely possible, without everyone deferring to the DBMS companies to do everything for us. Maybe it's time for me to publish something more official on this? Regards, T _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
