nicht angemeldet
Hi Andreas,
Reines HTTP hat ein paar Vorteile:
- Du brauchst Dich um die Übertragung gar nicht zu kümmern, nur noch um die "Nutzlast" der Übertragung - sprich: was tatsächlich übertragen wird.
Bin mittlerweile auch zum Entschluss gekommen, dass HTTP doch wieder mal das beste, weil einfachste und zuverlässigste ist... nicht nur, weil die SOAP- wie RPC-Steuerung in PHP immer noch recht kompliziert (vor allem natürlich für den Schnittstellenuser, der sich mit dieser Technik dann auch mehr oder weniger auseinandersetzen und vor allem zuschauen muss, dass er es auf seinem Server auch zum Laufen bekommt...) einzubauen ist. ;)
- in vielen Firmen sind die Firewalls so konfiguriert, daß außer den "Standard"-Ports für E-Mail und eben HTTP so gut wie nichts durchgelassen wird; wenn Du also ein eigenes Protokoll auf einem eigenen Port benutzt, schließt Du viele potentielle Nutzer aus.
Wenn sich der Server selbst ändert: einen Proxy dazwischen hängen, der jeweils auf den aktuellen Server greift. Damit verschiebst Du das Problem aber auch nur vom eigentlichen Server auf den Proxy (wenn sich der Proxy ändert ...)
Ja, auf dem Erkenntnisstand bin ich zuletzt auch steckengeblieben, aber sehen wir es mal eher realistisch und nicht so negativ: :)
Es geht wohl ohne großen Aufwand nicht anders, als irgendeinen fixen Serverpunkt zu definieren, der entweder auf einen anderen verweist oder selber die Anfrage bearbeitet - was ja nachträglich zumindest jederzeit änderbar ist.
Natürlich kann ich noch anbieten, dass der User beim Download seine Email-Adresse (oder gleich FTP-Daten? :D ) eingeben kann, damit er im Falle entscheidender Änderungen wie z.B. Serverwechsel benachrichtigt werden kann. ;)
Dank und Gruß!
Michi
MudGuard