Hey,
ich bin gerade dabei, ein eigenes Update System zu schreiben und hatte vorhin den Einfall, dass ich hier vielleicht mal fragen könnte, was ihr noch so für Ideen habt, weil es einfacher ist, sowas jetzt umzusetzen, als das dann später zu maschen. Hier sind meine Anforderungen an das Update System, die ich auf jeden Fall umsetzen werde:

• Kein FTP(S) oder SFTP für das normale arbeiten -> alles wird über serverseitige Scripte (PHP) geregelt
  • Hat den Vorteil, dass nicht unbedingt ein FTP Server laufen muss. Außerdem sind somit nicht die FTP Daten erforderlich; sollten die Schlüssel gestohlen werden, könnte der Angreifer höchstens Updates löschen (und nicht den kompletten Server, was der Fall wäre, wenn die FTP Daten gestohlen werden)
• Delta Patching (also Dateien, die nur die wirklichen Änderungen enthalten, was zu deutlich kleineren Updates führt)
• Saubere Versionssprünge
  
  • Jede Datei hat eine eigene Zeile in der Tabelle. Sollte nun der Benutzer von Version 1.0.0 auf 5.0.0 springen wollen, würde das Script nur die Unterschiede zwischen den beiden Updates untersuchen. Rollbacks, Repair sowie Downgrades sind dadurch auch möglich
  • Tasks werden korrekt geordnet/es muss angegeben werden, ob ein Task auch ausgeführt werden soll, wenn die Version übersprungen wird
• Lizenzüberprüfung soll möglich sein / das Update System muss gut in kommerzielle Projekte integriert werden können
• Administrative Funktionen wie Rollbacks, Delayed Publishing, sauberes Bearbeiten von Updatepakten, Zwangsupdates, etc. sind verfügbar
• Verschiedene Dateien für verschiedene Architekturen (x64, x86, Mono, etc.) im selben Updatepaket
• Kompatibel zu portablen Programmen
• Plattformunabhängigkeit für die Library
  • Mono kompatibel und eine Portable Class Library (da muss ich mich aber erst noch einlesen)
• Ausführliche Statistiken zu Benutzeraktivität hinsichtlich Updates (wann suchen Nutzer updates, welche Nutzer benutzen aktuell welche Version, wann wurde welches Update heruntergeladen, welche Benutzer sind gerade aktiv)
• Semantic Versioning
• Markdown unterstütze, mehrsprachige Changelogs
• Ein Server, mehrere Projekte
• Mirror Server
  • Man kann beliebig viele Server für jedes Projekt auswählen. Alle Server werden bei jedem Start synchronisiert
  • Es müssen nie alle Server online sein, die Server, die offline waren, werden einfach beim nächsten Start auf den aktuellen Stand gebracht
  • Server können geklont werden
• Sicherheit (also die Standardsachen wie Updates signieren etc.)
• Keine Grenzen beim expandieren, 1000 Updatepakete sollen kein Problem für die Performance sein
• Vereinfachungen beim Erstellen von Updatepaketen, also dass z. B. direkt überprüft werden kann, welche Dateien sich verändert haben; die Changelog Sprachen aus dem letzten Update werden übernommen, usw.

Das ganze wird dann eine Mischung aus nUpdate, UpdateSystem.Net und meinen eigenen Ideen. Ich hatte auch kurz überlegt, z. B. nUpdate zu forken, aber das ist doch etwas ziemlich anderes, bei Plattformunabhängikeit schreibe ich den Code am liebsten komplett selber. Hat noch jemand Ideen?

*Topic verschoben*

@KidRick
Das dürfte tatsächlich gar nicht mal so schwer sein; der Hauptcode wird in PHP ausgeführt, ich stelle mir das so vor:
Der Client macht eine Request an: https://www.domain.com/updatesystem.php?method=searchUpdate&api=1&version=1.0.2&architecture=winx64&hadwareId=FFFFFFFFFF&languageCulture=de-de

Dann checkt die PHP Datei 1) ob es neue Versionen gibt, welche die TargetVersion sein wird, 2) welche Dateien aktualisiert werden müssen, mit Berücksichtigung auf Service Packs usw. 3) wird nach Delta Patches geguckt, ob sich diese lohnen würden 4) werden die changelogs in der angegebenen Sprache gesucht 5) wird das alles als JSON ausgegeben. Praktisch gesehen muss das dann nur geparst und verarbeitet werden. Ich kann jetzt kein C++, aber vielleicht findet sich ja jemand, der mich da unterstützen könnte (vielleicht lerne ich ja sogar noch ein bisschen C++)

@newcat
Plan ist, dass es eine Basis-Bibliothek gibt, die nur die Funktionen beinhaltet, z. B. UpdateSystem. Dann gibt es halt UpdateSystem.WinForms, UpdateSystem.Wpf, usw.

@thefiloe
Ein PHP Server wird so oder so benötigt, anders ist das gar nicht umsetzbar. Eigentlich ist es relativ egal, ob alleine über PHP oder über PHP und FTP (PHP wird sowieso benötigt, weil es müssen ja auch Änderungen in der Datenbank gemacht werden und die ist meistens nur über localhost erreichbar), so habe ich eine Abhängigkeit weniger.

@Mokki
Ich bin jetzt nicht unbedingt der absolute Anfänger, wenn es um sowas geht, natürlich muss man aufpassen, welche Rechte wer haben darf. Das ganze wird ja auch Open Source, sodass das jeder überprüfen kann.

@X-Zat
Hab mir das gerade mal angeguckt, hat mich jetzt aber nicht so überzeugt. 1. gibt es kaum node.js Server, hingegen gibt es tausende kostenlose php Serverangebote. Dazu kommt, dass eigentlich sowieso jeder mit einer Website auch php Scripts ausführen kann. 2. Habe ich noch nie etwas mit node.js oder Javascript gemacht, Javascript hat jetzt auch nicht so den besten Ruf (nagut, man kann ja auch typescript verwenden), mit php habe ich schon ein paar Erfahrungen gesammelt.

Aber das sieht auf jeden Fall interessant aus, vielleicht gucke ich mir das auch mal irgendwann an.

Dein Punkt mit den Datenbanken verstehe ich nicht, es muss ja trotzdem ein Script laufen, welches die Daten verarbeitet.

@thefiloe, @X-Zat
So wie ich das sehe, muss man sich derzeit einen vServer kaufen, wenn man node.js Anwendungen laufen lassen will. Das ist wesentlich komplizierter, als wenn man sich einfach ein bisschen Webspace kauft, den man über das CPanel einrichten kann, es gibt keine kostenlosen Angebote, hingegen sind meistens die Angebote für Node.js Server wesentlich teurer als für einen normalen Webspace mit PHP und 2 MySQL Datenbanken. Außerdem erschließt sich mir der Sinn von Node.js nicht wirklich: So wie ich das sehe ist das einfach nur eine plattformunabhängige Programmiersprache, die man auf einem Linux Server laufen lässt und die dann einen Webserver auf einem bestimmten Port starten kann. Wieso brauche ich das? Ein Argument, welches ich gefunden habe, ist Performance, aber wieso soll ich dann nicht einen Server in C# schreiben, den der Nutzer dann über Mono laufen lässt? Das wäre wahrscheinlich noch viel schneller und besser, aber die Leute brauchen dann halt einen vServer.
Hat nicht gerade auch @thefiloe immer gegen private Root- und vServer gesprochen, wenn der Nutzer keine Ahnung hat? Wieso ist das denn jetzt ok?

X-Zat schrieb:

Ich würde mich keinesfalls auf Php-Server beschränken

Der Umkehrschluss wäre aber, sich auf vServer zu beschränken. Man beschränkt sich ja auch nicht einfach nur auf PHP-Server, man kann ja immer noch eine Node.js Implementierung machen, der Port würde wahrscheinlich wenige Stunden dauern, weil es halt echt wenig Arbeit ist (und vorallem, wie du schon sagtest, sind schon viele Libraries da, wie z. B. auch eine für SemVer). Ich bleibe trotzdem erstmal bei PHP, das wird aus meiner Sicht die größere Nutzerbasis finden und das ist erstmal wichtiger.