hotti: Neuer Artikel, bitte um Kritik

hi,

s. Thema. Im Artikel geht es um Dateiupload und Single Content. Es ergibt sich eine erstaunlich einfache Lösung für den Dateitransfer, die automatisierungsfreundlich ist.

Der Dateiname u.a. Dateiattribute werden dazu in den Request-Header eingebaut und sind serverseitig als HTTP_MYVARIABLE verfügbar. Interessante Möglichkeiten also für die Schnittstelle Projektverwaltung => Publizieren, sowie Content Management im Allgemeinen.

Filetransfer Single Content mit HTTP

Viele Grüße,
Rolf

  1. Filetransfer Single Content mit HTTP

    Konkret gefragt: Welchen Vorteil hat deine Lösung gegenüber der etablierten?

    Allgemein gefragt: Warum verwendest du so viel Zeit und Energie für die Lösung von Fragen, die seit langer Zeit stabil und verlässlich beantwortet sind, um sie danach noch mit erkennbarer Hingabe zu dokumentieren?

  2. Moin,

    Im Artikel geht es um Dateiupload und Single Content. Es ergibt sich eine erstaunlich einfache Lösung für den Dateitransfer, die automatisierungsfreundlich ist.

    das mag schon sein - trotzdem halte ich den Weg, den du im Artikel beschreibst, für wenig praxisrelevant, weil ich nicht nur das serverseitige Script für den Upload brauche, sondern auch noch eine clientseitige Sonderlösung.

    Interessante Möglichkeiten also für die Schnittstelle Projektverwaltung => Publizieren, sowie Content Management im Allgemeinen.

    Vielleicht, aber nicht für Content Management durch den Kunden selbst. Dem ist es nämlich lieber, wenn er seine vertraute Umgebung (z.B. seinen gewohnten Browser) benutzen kann, anstatt sich noch etwas Neues anzulernen.

    Filetransfer Single Content mit HTTP

    Von der Praxisrelevanz abgesehen: Du schreibst, dass dein implementierter HTTP-Upload mindestens um den Faktor 2 schneller sei als FTP. Ich halte diese Behauptung für eine nicht zulässige Verallgemeinerung deines individuellen Test Case.

    Du schreibst, du hättest das anhand einer rund 2MB großen Datei getestet. Die reine Übertragungszeit für 2MB Rohdaten beträgt bei einem gut "flutschenden" DSL6000-Anschluss etwa 3..4 Sekunden, bei einem schnelleren Anschluss entsprechend weniger. Bei DSL16000 könnten wir mit der reinen Transferdauer schon in die Größenordnung von nur einer Sekunde kommen.
    Sowohl FTP als auch deine HTTP-Variante übertragen uncodierte Binärdaten. Hier kann also kein Unterschied herkommen. Aber FTP hat etwas mehr protokollarischen Overhead, und erfahrungsgemäß legen viele FTP-Clients (oder Server, kann auch sein) eine mehr oder weniger lange Kunstpause ein, bevor sie endlich mit dem Transfer beginnen. Deine Beobachtung, dass FTP doppelt so lange braucht (oder gar noch länger), könnte also an genau dieser Pause vor dem Transfer liegen. Bei größeren Datenmengen, wenn wir in Gedanken mal auf 100MB oder mehr gehen, dürfte sich der Zeitbedarf beider Lösungen kaum noch unterscheiden.

    Fazit aus meiner Sicht: Technisch-akademisch interessant, für den Eigengebrauch vielleicht okay, aber nicht unbedingt für die Allgemeinheit geeignet.

    So long,
     Martin

    --
    Der Stress von heute ist die gute alte Zeit von morgen.
  3. Hi hotti,

    ich denke das der Performance Test zu kurz ausgefallen ist. Eine Tabelle mit folgenden Inhalt, würde den Artikel deutlich aufwerten.

    MB   | HTTP | FTP

    2   |      |
     5   |      |
    10   |      |
    20   |      |
    30   |      |
    ...  |      |
    100  |      |

    MfG
    Otto