datenbankomponenten unter linux

' schrieb:Zu deiner Library, du hast nicht zufällig Lust die offenzulegen? Ich denke das könnte einigen Leuten ne Menge Arbeit sparen - mich eventl. eingeschlossen

Also da gibts eigentlich vor allem zwei Probleme.

1) Der shared library source code enthält Dinge die ich nicht einfach so offenlegen kann und will.
2) Zweitens ich müsste mal was Zeit frei machen um die LabVIEW Library die von dieser shared library Gebrauch macht noch etwas aufzuräumen und zu dokumentieren. Es ist zwar schon einiges vorhanden aber viele Funktionen sind nur soweit getestet wie ich sie selber benütze, was bis jetzt hauptsächlich mit SQL Server zur Abspeicherung und dem Zurücklesen von Testresultaten geschehen ist.

Ohne Einsatz von anderen Leuten die die Benützung dieser Library mit anderen Datenbanken und auf den verschiedenen Plattformen dokumentieren wollen ist das nicht zu tun. Wenn sich da ein paar melden wollen, die bereit wären diese Library selber zu testen und aktiv Feedback zu geben, sowie eventuel kurze Tutorials zu schreiben wie das mit einer bestimmten Datenbank zum Laufen gebracht werden kann dann würde ich mich "motiviert" sehen die LabVIEW Library (ohne den C source code allerdings) unter einer Open-Source Lizenz verfügbar zu machen. Ich bin im Moment in der Lage um die entsprechende Shared Library für Windows 32bit und Linux Ubuntu (und kompatible d.h. unixodbc, aber würde wohl nicht mit libiodbc funktionieren) zu kompilieren und verfügbar zu machen.

Rolf Kalbermatter

Anzeige

Hallo rolfk,

unabhängig davon wie weit du schon bist, wenn du den Code nicht offenlegen kannst macht ein Engagement dahingehend keinen Sinn. Open Source = offene Quellen. Schade.

Wie gesagt, ich werd ma schaun, in wieweit ich Kapazitäten hab was zu tun. So ein paar Ideen hab ich bereits: Implementierung einer WrapperDLL um libpg.dll Funktionen unter LV aufrufen zu können, und dann VIs erstellen, die mir bequemen Zugriff auf diese Funktionen geben, die ich dann in meine Funktionspallete aufnehmen kann.Wenn jemand Ideen hat, oder mitmachen will, sage bescheid.

Viele Grüße
t4b-1re-2

' schrieb:Hallo rolfk,

unabhängig davon wie weit du schon bist, wenn du den Code nicht offenlegen kannst macht ein Engagement dahingehend keinen Sinn. Open Source = offene Quellen. Schade.

Es ist halt immer auch die Frage wie weit Open Source geht. Wenn Du eine LabVIEW Library unter Open Source herausgibst heisst das ja auch nicht dass Du den Sourcecode von LabVIEW mitlieferst. Und meine shared library macht halt Gebrauch von nicht ganz so offiziellen Dingen in der LabVIEW C API Schnittstelle, und deshalb sehe ich das auch nicht als Möglichkeit, um das öffentlich zu machen.

Rolf Kalbermatter

High nochmal,

' schrieb:Es ist halt immer auch die Frage wie weit Open Source geht. Wenn Du eine LabVIEW Library unter Open Source herausgibst heisst das ja auch nicht dass Du den Sourcecode von LabVIEW mitlieferst.

nö, hab ich auch nicht behauptet. Macht ja auch keinen Sinn. Es macht aber nunmal genauso wenig Sinn Zeit und Kraft in die Entwicklung eines Programmes zu stecken, welches auf binaries basiert von denen keiner weiß ob sie wirklich den Anforderungen genügen, sicher sind, die nicht offiziell sind usw... (is nicht böse gemeint). Weil im Zweifel, stellt sich zu einem späten Entwicklungstand, das das gesamte Projekt in den Sand gesetzt ist, weil irgendwas wichtiges nicht geht.

' schrieb:Und meine shared library macht halt Gebrauch von nicht ganz so offiziellen Dingen in der LabVIEW C API Schnittstelle, und deshalb sehe ich das auch nicht als Möglichkeit, um das öffentlich zu machen.

versteh ich nicht ganz: Entweder du nutzt die LV C API (die ja dazu da ist verwendet zu werden, also ist es auch offiziell und eventl. nur nicht ordentlich dokumentiert) oder du greifst in LV interne Nicht-API Prozesse ein, was dann quasi Lücken in LV wären. Da ist dann die Frage ob du das offiziell darfst und wie du es rausgefunden hast: Durch Zufall oder Reverse Engineering, oder du steckst mit in der LV-Entwicklung drinn. In den beiden ersten Fällen macht es keinen Sinn ein weiteres, ich meine offizielles Projekt darauf aufzubaun - weil zu riskant. In letzterem Fall stellt sich aber erst Recht die Sinnfrage.

Nichts für ungut
t4b-1re-2

Hallo,

nur so, als Zwischenmeldung ich hatte mich geirrt, das C-Interface libpg.dll von PostgreSQL lässt sich doch mit LabVIEW verwenden. Ein paar simple Kniffe und es geht, brauchte halt bis ich mich in das LabVIEWsche *** reingedacht habe. Ich bin gerade dabei mir darauf aufbauend einige rudimentäre Komponenten zu zeichnen. Falls wer interesse hat und mitmachen will - ansagen. Andernfalls, dauerts noch etwas bis das frei wird.

t4b-1re-2

Zur Info warum ich das tue: Weil ich defnitiv plattforunabhänigen (Linux, Windows etc.) Zugriff von LabVIEW auf PostgreSQL brauche.