Lustig

[Anton Lustig]

Ist schon lustig, wenn z.B. Frames mit Ajax nachprogrammiert werden. Google kann die verpönten Frames locker indizieren, Ajax-Inhalte bislang nicht. Vielleicht sollten wir doch besser Frames verwenden?

Es ist des öfteren so, daß eine "neue" Technik zum Hype erkoren wird, um dann mit allerlei Bastelei drumherum alte Funktionalität wieder herzustellen. Auch ein schönes Beispiel:

HTTP -> REST -> Cookies -> Sessions -> Ajax -> Comet -> Wave -> Web Storage -> Gears -> Native Client

Und jetzt also ein extra Protokoll, das Google auch die Ajax-Inhalte lesen kann.

Oder - anderes Beispiel - Nachprogrammierung von nativen GUI's und Anwendungen im Webbrowser mit JavaScript, Flash, Silverleight etc., nach dem, welch Wunder, ein simples HTML-Webinterface eben doch nicht der Weisheit letzter Schluß zu sein scheint.

Vor HTTP hat das alles schon mal funktioniert. Ob das damals wirklich schlechter skaliert hat als der Wust von Aufsätzen und Stapeleien von Frameworks over Frameworks, Servern, VM's, Sandboxen, Datenbanken, DAL's, Bussines Layern, sonstigen Interfaces, Pattern-Engines (MVC/MVC2/MVP/PAC ... oh je) und Templateengines heute?

Oder - anderes Bespiel - man blockiert/verbietet möglichst alle IP-Ports und tunnelt anschließend sukzessive die gesamte Funktionalität (inkl. Schadsoftware) viel aufwendiger über komplizierte Protokollaufsätze durch HTTP. Ein Port muß ja schließlich immer offen sein. (Eigentlich könnte man doch "Ports" gleich aus IP entfernen, wenn eh' einer reicht, oder?)

Meiner persönlichen Meinung (und Erfahrung) nach haben durch die aufgezwungene Komplexität viele Groß- und Kleinprojekte das Problem, für einfachste Funktionalität monströse Systemarchitekturen entwickeln zu müssen mit einer riesen Herde von Programmiersklaven und Zitronenfaltern. Auch mit entsprechend vielen potentiellen Fehlerquellen. Und alle Beteiligten sind auch noch prinzipbedingt kreative Köche, die man mit allerlei Vorgehensmodellen versucht, irgendwie unter einen Hut zu bekommen.

Ich habe hier ein kleines in Assembler geschriebenes vollständiges Windows-GUI-Chatprogramm, das ist 14 KB groß, wovon noch 12 KB auf eine eingebettete Bildressource gehen, sprich: das eigentlich Programm ist 2 KB groß. Mehr bedarf es also nicht, um im gegebenen Kontext die Funktionalität einer Chat-Anwendung samt GUI zu beschreiben. Man kann das natürlich auch via Google Wave machen und liste dann mal die dabei involvierten Technolgien, Protokolle und transportierten Datenmengen auf.

Auch wenn Assembler im Beispiel natürlich sicherheitstechnisch problematisch und maschinenabhängig ist und man mit Google Wave manches mehr machen kann, wie mit Assembler aber auch, stehen meiner ganz persönlichen Meinung nach der Aufwand, Performance- und Ressourcenverbrauch zur Funktionalität bei heutigen Entwicklungen in keiner sinnvollen Relation mehr.

Mach es „So einfach wie möglich. Aber nicht einfacher.“ (Albert Einstein?)

(Sorry für die Ausschweifungen)

[fail]

Anton Lustig schrieb:
--------------------------------------------------------------------------------
> (Eigentlich könnte man doch "Ports" gleich aus IP entfernen, wenn eh' einer reicht, oder?)

you fail ;)

[Anton Lustig]

fail schrieb:
--------------------------------------------------------------------------------
> Anton Lustig schrieb:
> ---------------------------------------------------------------------------
> -----
> > (Eigentlich könnte man doch "Ports" gleich aus IP entfernen, wenn eh'
> einer reicht, oder?)
>
> you fail ;)

Ok, der Port ist eine Ergänzung zur IP-Adresse bei TCP und UDP etc. Korrekter wäre also "Ports" bei UDP/TCP zu entfernen, wenn eh alles nur noch über TCP Port 80/HTTP geht.

Oder irre ich noch an anderer Stelle?

[asdasd]

Na, Einstein hatte auch net immer recht ;-)

[Dominic]

Hey,

ich stimme dir da größtenteils zu. AJAX z.B. ist eine tolle Sache wenn es im Rahmen bleibt. Ganze Seiten über einen Request zu laden ist absolut unnötig und man hat keinerlei Vorteile davon. Kleine Teile nachzuladen ist hingegen sehr praktisch.

Gruß,
Dominic

[Verwundert]

Anton Lustig schrieb:
--------------------------------------------------------------------------------
> fail schrieb:
> ---------------------------------------------------------------------------
> -----
> > Anton Lustig schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > (Eigentlich könnte man doch "Ports" gleich aus IP entfernen, wenn eh'
> > einer reicht, oder?)
> >
> > you fail ;)
>
> Ok, der Port ist eine Ergänzung zur IP-Adresse bei TCP und UDP etc.
> Korrekter wäre also "Ports" bei UDP/TCP zu entfernen, wenn eh alles nur
> noch über TCP Port 80/HTTP geht.
>
> Oder irre ich noch an anderer Stelle?

Ja verdammt nochmal, auc bei HTTP brauchst du mehr als einen Port nämlich auf Clientseite, der ist nämlich NICHT 80 und pro gleichzeitiger Verbindung wäre einer davon nett

Eine Verbindung besteht aus mindestens VIER Parametern
SOURCE-IP:TARGET-PORT -> TARGET-IP:SOURCE-PORT
DEINE:80 -> SERVER-IP:EINER ZW. 1024 UND 65535 BEI DIR

Du irrst in einem Umfang dass es dir besser zu Gesicht stehen würde zu Themen von denen du nicht die geringste Ahnung hast gänzlich zu schweigen!