Am Mittwoch, 31. Mai 2017, 22:11:24 CEST schrieb Simon Kurka via Dev:
Den Rest des Paketes kann man auch schützen.
Kannst du kurz beschreiben was man dazu machen muss oder mir nen Hinweis auf Doku geben?
Bisher wurde kein Mehrnutzen genannt (respondd kann alle Daten liefern), daher bin ich dagegen.
Ich wiederhole mich: wer das Know-How und die Zeit hat einen Client zu schreiben, der sich zwischen Respondd und die API setzt um die Daten zu Syncen, quasi ein Crawler, der möge das bitte unbedingt tun! Ich bin da über die Umsetzung alternativer Ansätze jederzeit Dankbar. Wenn das so einfach und vorteilhaft ist und das jemand evaluieren, umsetzen und Maintainen will, warum diskutieren wir dann noch?
Insgesamt kann ich der Diskussion nicht mehr folgen. Als ich die Entwicklung vor zwei Jahren gestartet habe war Grundlage, dass wir einen Verbesserungsbedarf bei der Verwaltung und Visualisierung unseres Netzes sehen. Außerdem bestand bisher der dringende Bedarf bestimmte Prozesse bei Aufbau und Betrieb des Netzes (Abwicklung von Förderprogrammen, regelmäßige Wartung und Information im Fehlerfall) zu unterstützen sowie das Verknüpfen der Netz-Daten mit weiteren Informationen bspw. zum Standort zu ermöglichen.
Jetzt wo die Entwicklung zu einem brauchbaren Stand gekommen ist, fangen einige hier an zu mauern wo es nur geht und ziehen mich Stundenlang in eine Diskussion um einen Punkt der allen Testern hilft, stabil ist und jederzeit schadlos rückgängig gemacht werden kann?
Ich bin an zwei Dingen interessiert: * Wie kann man Pakete über Firmware-Upgrade preserven (ganz unabhängig von der Diskussion fände ich das Feature sehr praktisch) * Entwickler die Bock haben einen Respondd2Netmon-Client zu evaluieren, zu entwickeln und zu maintainen
Von meiner Seite aus steht der Integration des Node-Clients nichts im Weg. Zum Rest der Diskussion ist alles gesagt sodass ich mich darauf konzentriere den Rest zu testen und zu signieren.
Viele Grüße Clemens