Open phonovision opened 8 years ago
Der bessere Weg wäre diesse Repository zu forken und dann einen entsprechenden pullrequest zusenden. Ein kompett unabhängiges repository macht IMHO wenig Sinn.
@6triple8 Verstehe ich das richtig? Du hast Dir eine eigene libXmlRpc.so (die lib die dann vom rfd z.b. genutzt wird?) gebaut? Und da fehlt dann die BIN-RPC Unterstützung? eQ-3 hat ja die Sourcen seiner BIN-RPC Implementierung (noch?) gar nicht veröffentlicht, insofern hast Du ja jetzt quasi eine libxmlrpc.so ohne eQ-3 Patches? Spielt das noch mit der Rega zusammen? Und wie ist das mit dem 64 Bit System zu verstehen? rfd, hs485d und rega gibts ja eh auch nur als i386 (32bit) binaries die auch auf einem 64bit-system ihre 32bit-libs benötigen. Irgendwas versteh ich glaube ich falsch, bitte um Aufklärung :)
@hobbyquaker Ich habe mir meine eigene libXmlRpc.so gebaut und zwar mit BIN-RPC. Die Sourcen dafür liegen in https://github.com/eq-3/occu/blob/master/CCU2/download/xmlrpc-eQ-3.tar.gz - aber wie erwähnt eben nur als Archiv, was für eine Versionierung nicht so sinnvoll ist.
Ich verende XmlRpc++ für die Kommunikation mit dem RFD und auf meinem Entwicklungsrechner habe ich eben eine x64-Umgebung (RFD läuft wahlweise in der VM oder auf der CCU2).
@jens-maus Es geht darum, dass XmlRpc++ nur in gepackter Form vorliegt. Forken, das Archiv patchen und dann einen Pullrequest zu senden erscheint mir dann doch grenzwertig.
Und auch wenn ich das Archiv in entpackter Form einchecken würde, bliebe da doch ein fader Beigeschmack, da ich die Bibliothek eigentlich nicht alleine als Bestandteil von OCCU ansehe. Prinzipiell kann sie ja auch von anderen Programmen verwendet werden.
Daher würde ich XmlRpc++ in ein eigenes Repository legen. Dort würde ich dann gerne von den originalen Quellen ausgehen und erst im zweiten Schritt auf die von eQ-3 bearbeitete Fassung gehen. Das hätte den Vorteil, dass man die Unterschiede gut sehen und eventuell auch zwischenzeitliche Änderungen an der originalen Fassung übertragen könnte.
@6triple8: Ist die Änderungen so vorgenommen worden, dass Sie auch auf einem 32bit System weiterhin funktioniert? Falls ja, würde ich die Library unter CCU2/Source/xmlrpc auspacken. Du könntest dann das Repository forken, deine Änderungen durchführen und einzuchecken und dann einen Pull Request zu stellen.
Ja, es sollte auch auf einem 32-Bit-system funktionieren, das sollte ich aber noch überprüfen.
XmlRpc++, an implementation of the XmlRpc protocol written in C++, based upon Shilad Sen's excellent py-xmlrpc library.
Werden mal schauen ob mit der Orginalen py-xmlrpc den RFD Server anzusprechen ist mit den Unterlagen.
Wenn die XmlRpc++ stark verändert wurden ist und somit von der xmlrpc Norm abweicht, wäre ein neuen Namesgebung wünschenswert. Damit wäre klar das es kein orginales XmlRpc-Protokoll mehr ist.
Frage ist die Aussage:
"rfd, hs485d und rega gibts ja eh auch nur als i386 (32bit) binaries die auch auf einem 64bit-system ihre 32bit-libs benötigen. Irgendwas versteh ich glaube ich falsch, bitte um Aufklärung :)"
eigendlich aktuell in Anbetracht der Möglichkeit es auf den Raspberry laufen zu lassen?
Dies ist zwar ein recht altes Ticket inzwischen, aber gibt es die Anpassungen von @phonovision irgendwo? Ich würde sie mir gerne einmal näher anschauen wollen.
Die in OCCU enthaltene XmlRpc++-Version enthält Änderungen von eQ-3, die offenbar die Unterstützung von BIN-RPC ermöglichen. Bei der Verwendung auf einer 64-Bit-Architektur bin ich auf Probleme gestoßen, die ich jedoch beheben konnte.
Jetzt stellt sich die Frage, wie ich die Änderungen veröffentlichen kann. In OCCU ist XmlRpc++ nur als gepacktes Archiv enthalten, daher erscheint mir eine Veröffentlichung direkt in diesem Repository in Hinblick auf die Quellcode-Versionierung nicht besonders sinnvoll. Sofern keine nennenswerten Gründe dagegen sprechen, würde ich stattdessen bei https://github.com/codeatelier ein eigenständiges Repository verwenden und hier über die README.md darauf verlinken.