RSS Feeds

[Ludger]

Hi,

kann man einen RSS Feed soz. auch als Chat verstehen? Wo waeren ggf. die Unterschiede?

Gruss,
Ludger

[fastix®]

Moin!

kann man einen RSS Feed soz. auch als Chat verstehen? Wo waeren ggf. die Unterschiede?

Nein. Ein RSS- Feed wird aus einem CMS-artigem etwas erstellt und ist XML. Mit Chatten hat das ganz und gar nichts zu tun. Es geht darum Nachrichten (headlines) zu publizieren.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Sebastian Becker]

Hallo,

kann man einen RSS Feed soz. auch als Chat verstehen? Wo waeren ggf. die Unterschiede?
Nein. Ein RSS- Feed wird aus einem CMS-artigem etwas erstellt und ist XML. Mit Chatten hat das ganz und gar nichts zu tun. Es geht darum Nachrichten (headlines) zu publizieren.

Wobei man der Korrektheit halber dazu sagen müsste, daß man einen Chat oder ein Forum theoretisch natürlich auch als RSS/XML-Feed anbieten könnte, um diesen in eine andere Seite einzubinden.

Siehe auch http://en.wikipedia.org/wiki/Rss

Grüße,

Sebastian

[Ludger]

Hi,

Siehe auch http://en.wikipedia.org/wiki/Rss

habichschongelesen.   ;-)

Um mal ein wenig abstrakter zu werden: Ein RSS Feed Reader sendet in bestimmten zeitlichen Abstaenden HTTP-XML Requests an einen Webserver. Dieser antwortet.

Wir haetten da sowas wie ein "Pull-Daten-Abo", ein traditioneller Chat waere ein "Push-Daten-Abo", wobei wber wegen der permanenten Verbindung ueber ein "geeignetes" Protokoll (IRC) mehr Traffic entstehen wuerde?

Ist die Legende, dass HTTP fuer Chats ungeeignet ist, "somit" widerlegt?  ;-)

Gruss,
Ludger

[Henryk Plötz]

Moin,

Um mal ein wenig abstrakter zu werden: Ein RSS Feed Reader sendet in bestimmten zeitlichen Abstaenden HTTP-XML Requests an einen Webserver.

Nein. Und bitte werde nicht wieder "abstrakt". Da kommt jedes mal Mist bei raus.

[Ludger]

Hi, Henryk,

Um mal ein wenig abstrakter zu werden: Ein RSS Feed Reader sendet in bestimmten zeitlichen Abstaenden HTTP-XML Requests an einen Webserver.

Nein. Und bitte werde nicht wieder "abstrakt". Da kommt jedes mal Mist bei raus.

Du hast wieder mal ueberhaupt nichts verstanden, stimmts?

Gruss,
Ludger

[Henryk Plötz]

Moin,

Du hast wieder mal ueberhaupt nichts verstanden, stimmts?

Hmm, und selbst? Und jetzt sage nicht, "HTTP-XML Request" würde von erweitertem Verständnis der Sache zeugen.

Mist, wo ist denn nur mein Popcorn ...

[Ludger]

Hi,

Du hast wieder mal ueberhaupt nichts verstanden, stimmts?

Hmm, und selbst? Und jetzt sage nicht, "HTTP-XML Request" würde von erweitertem Verständnis der Sache zeugen.

Mist, wo ist denn nur mein Popcorn ...

es ist doch HTTP-XML Kommunikation. Bitte bearbeite die Ausgangsfrage und friss, aeh iss, Dein Popcorn da wo es sich gehoert.

Gruss,
Ludger

[Raik]

Hallo, Ludger!

Bitte bearbeite die Ausgangsfrage ...

du meinst die hier?
   Wir haetten da sowas wie ein "Pull-Daten-Abo",
   ein traditioneller Chat waere ein "Push-Daten-Abo",
   wobei wber wegen der permanenten Verbindung ueber ein
   "geeignetes" Protokoll (IRC) mehr Traffic entstehen wuerde?
würdest du dich bitte zuerst darüber informieren, wie ein verbindungsaufbau über http abläuft und welcher overhead dabei gegenüber einer permanenten verbindung entsteht, bevor du hier thesen in die welt setzt? auch von dir wird (wie von jedem anderen) erwartet, dass du dir zumindest erst mal die grundlagener arbeitest, bevor du hier fragen stellst. besonders, wenn du diese auf grundlage ungeprüfter, falscher annahmen formulierst.

... und friss, aeh iss, Dein Popcorn da wo es sich gehoert.

wenn das wieder dein eigentümlicher humor sein soll, vergiss ihn. darüber wird hier auch nach dem hundertsten mal keiner lachen.
und ansonsten musst du dich bei sowas nicht wundern, wenn viele auf dich gereizt reagieren.

*popcorn und cola rausholt und sichs gemütlich macht*

freundl. Grüsse aus Berlin, Raik

[Ludger]

Hi,

du meinst die hier?
   Wir haetten da sowas wie ein "Pull-Daten-Abo",
   ein traditioneller Chat waere ein "Push-Daten-Abo",
   wobei wber wegen der permanenten Verbindung ueber ein
   "geeignetes" Protokoll (IRC) mehr Traffic entstehen wuerde?

ja, sowas verstehen hier anscheinend nur noch ein paar Leute.   :-(

würdest du dich bitte zuerst darüber informieren, wie ein verbindungsaufbau über http abläuft und welcher overhead dabei gegenüber einer permanenten verbindung entsteht, bevor du hier thesen in die welt setzt? auch von dir wird (wie von jedem anderen) erwartet, dass du dir zumindest erst mal die grundlagener arbeitest, bevor du hier fragen stellst. besonders, wenn du diese auf grundlage ungeprüfter, falscher annahmen formulierst.

Ein Plaedoyer gegen HTTP?   ;-)

Gruss nach Berlin,
Ludger

[Henryk Plötz]

Moin,

ja, sowas verstehen hier anscheinend nur noch ein paar Leute.   :-(

Wie schade, dass du nicht dazugehörst.

Ein Plaedoyer gegen HTTP?   ;-)

Gegen den missbräuchlichen Einsatz, sicherlich. HTTP ist kein Protokoll für Streams.

[Ludger]

Hi,

also, noch mal ganz verstaendlich, kann man einen Chat per RSS Feed und "Pull-Datenabo" effizient realisieren oder nicht?

Wird dann ggf. weniger oder mehr Traffic generiert? Und ist das dann gut oder schlecht?

Gruss,
Ludger

[Christian Kruse]

Hallo Ludger,

also, nochmal ganz verstaendlich:

also, noch mal ganz verstaendlich, kann man einen Chat per RSS Feed und "Pull-Datenabo"
effizient realisieren oder nicht?

Nein.

Wird dann ggf. weniger oder mehr Traffic generiert?

Mehr.

Und ist das dann gut oder schlecht?

Schlecht.

Grüße,
 CK

[Raik]

Hallo, Ludger!

also, noch mal ganz verstaendlich, kann man einen Chat per RSS Feed und "Pull-Datenabo" effizient realisieren oder nicht?
Wird dann ggf. weniger oder mehr Traffic generiert? Und ist das dann gut oder schlecht?

sag mal, selber denken ist wohl in deinem job nicht gut für die kariere? hier im forum schon.

freundl. Grüsse aus Berlin, Raik

[Ludger]

Hi,

also, noch mal ganz verstaendlich, kann man einen Chat per RSS Feed und "Pull-Datenabo" effizient realisieren oder nicht?
Wird dann ggf. weniger oder mehr Traffic generiert? Und ist das dann gut oder schlecht?

sag mal, selber denken ist wohl in deinem job nicht gut für die kariere? hier im forum schon.

sag mal, rubbelst Du Dir immer einen, wenn Du sowas schreibst?

Gruss,
Ludger

[fastix®]

Moin!

sag mal, rubbelst Du Dir immer einen, wenn Du sowas schreibst?

Lass das. Dies ist trotz wiederkehrender kleinerer aber heftiger Diskussionen mit gelegentlichen Ausbrüchen immer noch ein seriöses Forum. Sicher bist auch Du so oft hier, weil man sowas hier nicht allzuoft um die Ohren gehauen bekommt. Und wenn Du sowas nicht lesen willst- dann solltest Du es auch nicht schreiben. Selbst wenn die Diskussion manchmal hart ist.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Ludger]

Hi,

es war nur ein Zitat von Wilhelm Turtschan (welch eine Ausrede! ;-).

Aber Du hast natuerlich Recht. Dennoch zielt der von mir kommentierte Beitrag ganz klar nicht mehr auf die Sache, sondern auf die Person.

Gruss,
Ludger

[Raik]

Hallo, Ludger!

sag mal, selber denken ist wohl in deinem job nicht gut für die kariere? hier im forum schon.
sag mal, rubbelst Du Dir immer einen, wenn Du sowas schreibst?

nein, das bestimmt nicht. eher verdrehe ich die augen *nerv*, weil du, statt endlich erst mal die von jedem frager erwartete recherche zu den grundlagen deiner frage durchzuführen, diese immer wieder wiederholst.
nochmal zum mitmeisseln:
"Von allen hier Teilnehmenden werden HTML-Grundkenntnisse erwartet. Es wird erwartet, daß bei Problemen erst einmal in SELFHTML, im  Forumsarchiv oder in anderen Quellen nach einer Lösung gesucht wird."

inzwischen hast du übrigens so viele antworten erhalten, die alle aussagen, dass ein http-chat und effizienz antagonistische gegensätze sind. ich frage mich also jetzt, warum du die diskussion trotzdem weiter mit wenns und abers am leben zu halten versuchst.

freundl. Grüsse aus Berlin, Raik

[Thomas J.S.]

Hallo,

also, noch mal ganz verstaendlich, kann man einen Chat per RSS Feed und "Pull-Datenabo" effizient realisieren oder nicht?

Nein, weil --> 1)

Wird dann ggf. weniger oder mehr Traffic generiert? Und ist das dann gut oder schlecht?

1. Du willst sicherlich nicht immer die ganze RSS-Datei laden. Das müsste aber dein Programm, eben wie ein Feed-Reader das auch macht. Natürlich könntest du den Inhalt der Datei auf nur wenige Meldungen begrenzen und deinen Feeadreader so einstallen, dass er deine lokale Kopie erweitert.

Das betriftt aber noch immer nur den lesenden Zugriff. Wie willst du aber schreiben?

Außerdem wäre das Daten-Overhead für einen Chat in diesem Fall viel zu groß. Du müsstest für ein einfaches "Hallo" jede Menge Daten produzieren.

Grüße
Thomas

[Ludger]

Hi,

1. Du willst sicherlich nicht immer die ganze RSS-Datei laden. Das müsste aber dein Programm, eben wie ein Feed-Reader das auch macht.

danke fuer diese Info. Ich dachte, dass man da mit einem Sicherheits- bzw. Sitzungskontext kommen wuerde. Dieser waere in der Tat einfach erforderlich, wenn es effizient sein soll.

Natürlich könntest du den Inhalt der Datei auf nur wenige Meldungen begrenzen und deinen Feeadreader so einstallen, dass er deine lokale Kopie erweitert.

Ne, das meinte ich nicht.

Das betriftt aber noch immer nur den lesenden Zugriff. Wie willst du aber schreiben?

Nun, das geht nicht mit einem RSS Feed? (Weisst Du, ich arbeite in letzter Zeit mit SOAP und mit einigen XML-basierten Schnittstellen (unsere eigene Leasing API, Schufa-SIML u.s.w. - und da habe ich beim Trendy-RSS Feed auch den Schreibzugriff irgendwie erwartet.

Außerdem wäre das Daten-Overhead für einen Chat in diesem Fall viel zu groß. Du müsstest für ein einfaches "Hallo" jede Menge Daten produzieren.

Da hatte ich eben gewittert, dass es nicht so ist. Bedenke den Overhead fuer die vielen permanenten Verbindungen. Ich dachte, dass sich der RSS Feed z.B. eine Client-ID holt und einen anfaenglichen Datenhaufen, der dann inkrementell upgedated wird.

OK, also wie Du schreibst, kein Schreibzugriff im "RSS Feed Standard". Dann geht's wohl "eher" nicht. Muss man auf den XML-HTTP Chat noch ein wenig warten.   ;-)

Gruss,
Ludger

[Christian Seiler]

Hallo Ludger,

Da hatte ich eben gewittert, dass es nicht so ist. Bedenke den Overhead fuer die vielen permanenten Verbindungen.

Bitte, was ist daran Overhead? Bei einer TCP-Verbindung wird _NICHTS_ übermittelt, wenn gerade nichts gesprochen wird. Ok, im IRC-Protokoll sind noch so PINGs etc. eingebaut, aber die sind zu vernachlässigen, wenn Du vergleichst:

Szenario: Jede Sekunde wird die RSS-Datei abgefragt. Jede Sekunde wird folgendes gemacht:

1 Datenpaket SYN vom Client
1 Datenpaket SYN-ACK vom Server
1 Datenpaket ACK vom Server => TCP-Verbindung ist aufgebaut
1 Datenpaket mit dem HTTP-Request vom Client (ca. 1KB)
1 Datenpaket mit dem HTTP-Response-Header vom Server (auch ca. 1KB)
x Datenpakete mit der RSS-Datei vom Server (mindestens 4KB)
ein Paar Datenpakete, um die Verbindung wieder abzubauen

d.h. für ein einfaches Hallo übermittelst Du mindestens 7 KB über die Leitung, bei IRC sind's nur ein paar Byte.

Viele Grüße,
Christian

[Ludger]

Hi,

Da hatte ich eben gewittert, dass es nicht so ist. Bedenke den Overhead fuer die vielen permanenten Verbindungen.

Bitte, was ist daran Overhead? Bei einer TCP-Verbindung wird _NICHTS_ übermittelt, wenn gerade nichts gesprochen wird. Ok, im IRC-Protokoll sind noch so PINGs etc. eingebaut, aber die sind zu vernachlässigen, wenn Du vergleichst:

darum frage ich ja. Wieviele Chat-Clients koennen von einem normal dimensionierten Server so bedient werden? (Ich chatte nicht oft (wirklich selten, wirklich ;-)), aber ich sehe da oft so Limits pro Raum und anscheinend auch pro Server.)

Eine weitere huebsche Eigenschaft des skizzierten XML HTTP Chat Clients waere die potentiell fast unlimitierte Konfigurierbarkeit, wenn der Server mitspielt, meine ich.

Aber, wie gesagt, der RSS Feed Standard leistet, aehh unterstuetzt, das nicht.

Gruss,
Ludger

[Christian Seiler]

Hallo Ludger,

darum frage ich ja. Wieviele Chat-Clients koennen von einem normal dimensionierten Server so bedient werden?

Ich schätze mal, bis zu 250, ich habe das jedoch noch nie ausprobiert und kann deswegen auch ziemlich grob daneben liegen. Allerdings kann man mit IRC auch Netzwerke aufbauen, in denen mehrere Server miteinander verbunden sind, was dann die Anzahl an Clients drastisch erhöht.

Eine weitere huebsche Eigenschaft des skizzierten XML HTTP Chat Clients waere die potentiell fast unlimitierte Konfigurierbarkeit, wenn der Server mitspielt, meine ich.

Naja, Konfigurierbarkeit hast Du auch bei IRC.

Viele Grüße,
Christian

[Ludger]

Hi,

Ich schätze mal, bis zu 250, ich habe das jedoch noch nie ausprobiert und kann deswegen auch ziemlich grob daneben liegen. Allerdings kann man mit IRC auch Netzwerke aufbauen, in denen mehrere Server miteinander verbunden sind, was dann die Anzahl an Clients drastisch erhöht.

250 sind aber nicht so viele. Allerdings muesste auch ein XML HTTP Chatclient bei einer Aktualisierungsrate von einmal pro Sekunde ziemlich rackern. Vielleicht ist es doch eher etwas fuer ein Forum.   ;-)

Eine weitere huebsche Eigenschaft des skizzierten XML HTTP Chat Clients waere die potentiell fast unlimitierte Konfigurierbarkeit, wenn der Server mitspielt, meine ich.
Naja, Konfigurierbarkeit hast Du auch bei IRC.

Schoen strukturierte Metadaten und so waren gemeint. Ausserdem ist es cool die Aktualisierungsrate clientseitig einzustellen. Serverseitig kann diese natuerlich auch kontrolliert werden.

Gruss,
Ludger

[Andreas Korthaus]

Hi!

Schoen strukturierte Metadaten und so waren gemeint. Ausserdem ist es cool die Aktualisierungsrate clientseitig einzustellen. Serverseitig kann diese natuerlich auch kontrolliert werden.

Bei IRC brauchst Du im Prinzip keine Aktualisierungsrate. Wenn es neue Nachrichten gibt verbreitet der Server die über die bestehenden IRC-Verbindungen zu den Clients.

Vor ner Zeit hatte ich dazu mal was geschrieben: </archiv/2003/9/58291/#m327141>

Grüße
Andreas

[Christian Kruse]

Hallo Ludger,

Da hatte ich eben gewittert, dass es nicht so ist. Bedenke den Overhead fuer die vielen permanenten Verbindungen.

Bitte, was ist daran Overhead? Bei einer TCP-Verbindung wird _NICHTS_ übermittelt, wenn gerade nichts gesprochen wird. Ok, im IRC-Protokoll sind noch so PINGs etc. eingebaut, aber die sind zu vernachlässigen, wenn Du vergleichst:

darum frage ich ja. Wieviele Chat-Clients koennen von einem normal dimensionierten Server so bedient werden? (Ich chatte nicht oft (wirklich selten, wirklich ;-)), aber ich sehe da oft so Limits pro Raum und anscheinend auch pro Server.)

Maximal 65536 (2^16). Das in TCP eingebaute Limit.

Grüße,
 CK

[Henryk Plötz]

Moin,

Maximal 65536 (2^16). Das in TCP eingebaute Limit.

Hmm, wo? Also wenn schon ein TCP/IP-Limit dann eher 2^16*2^32. Lange vorher 'findet' man aber die Beschränkungen des Betriebssystems. Bei einigen kann man schon mehr als 1024 Sockets nicht mehr effizient (sprich: select()) bedienen.

[Christian Kruse]

Hallo Henryk,

Maximal 65536 (2^16). Das in TCP eingebaute Limit.

Hmm, wo?

Ein Rechner kann maximal 65536 Verbindungen bedienen, 2^16 halt. Fuer Ports sind 16 Bit
reserviert.

Also wenn schon ein TCP/IP-Limit dann eher 2^16*2^32.

Wie kommst du auf eine solche Zahl? TCP/IP sagt eindeutig, Port-Range ist auf 16 Bit
beschraenkt. Damit kann eine Maschine maximal 2^16 Verbindungen entgegen nehmen.

Lange vorher 'findet' man aber die Beschränkungen des Betriebssystems.

Das ist in der Tat richtig, ja, aber darum ging es mir ja nicht.

Grüße,
 CK

[Henryk Plötz]

Moin,

Ein Rechner kann maximal 65536 Verbindungen bedienen, 2^16 halt. Fuer Ports sind 16 Bit
reserviert.

Wie dir aber sicher bekannt ist wird in TCP eine Verbindung durch das Quadrupel Src-Address/Src-Port/Dst-Address/Dst-Port bestimmt. Die Anzahl der Ports auf einem Host hat nur sehr wenig mit der Anzahl der Verbindungen zu tun. Zu einem einzigen Port auf einem Host (Dst-Port und -Address fest) kann es also mindest 2^32 (Anzahl anderer Hosts; nagut, meinetwegen auch 2^32-1) mal 2^16 (Anzahl anderer Ports pro Host) Verbindungen geben.

[Christian Kruse]

Hallo Henryk,

Ein Rechner kann maximal 65536 Verbindungen bedienen, 2^16 halt. Fuer Ports sind 16 Bit
reserviert.

Wie dir aber sicher bekannt ist wird in TCP eine Verbindung durch das Quadrupel
Src-Address/Src-Port/Dst-Address/Dst-Port bestimmt.

Hm, ja, gut, du hast recht. Hehe, Verpeilung meinerseits.

Grüße,
 CK

[Ludger]

Hi,

Wieviele Chat-Clients koennen von einem normal dimensionierten Server so bedient werden?
Maximal 65536 (2^16). Das in TCP eingebaute Limit.
Lange vorher 'findet' man aber die Beschränkungen des Betriebssystems.
Das ist in der Tat richtig, ja, aber darum ging es mir ja nicht.

Dir ging es also nicht um die Bearbeitung der anfaenglichen Fragestellung. Nach dem Motto: erst mal die Fragestellung absichtlich falsch verstehen, Informationen zurueckhalten, dann ggf. argumentativ nachmunitionieren

Fragt sich nur, warum Du sowas machst.

Gruss,
Ludger

[Christian Kruse]

Hallo Ludger,

Hi,

Wieviele Chat-Clients koennen von einem normal dimensionierten Server so bedient
werden?
Maximal 65536 (2^16). Das in TCP eingebaute Limit.
Lange vorher 'findet' man aber die Beschränkungen des Betriebssystems.
Das ist in der Tat richtig, ja, aber darum ging es mir ja nicht.

Dir ging es also nicht um die Bearbeitung der anfaenglichen Fragestellung.

Doch. Aber es ging mir nicht um die durch das OS auferlegten Limits.

Fragt sich nur, warum Du sowas machst.

Warum stellst du derart idiotische und abwegige Fragen, die du dir mit Hilfe der
Grundrechenarten auch selbst beantworten koenntest?

Grüße,
 CK

[Ludger]

Hi,

Wieviele Chat-Clients koennen von einem normal dimensionierten Server so bedient
werden?
Maximal 65536 (2^16). Das in TCP eingebaute Limit.
Lange vorher 'findet' man aber die Beschränkungen des Betriebssystems.
Das ist in der Tat richtig, ja, aber darum ging es mir ja nicht.
Dir ging es also nicht um die Bearbeitung der anfaenglichen Fragestellung.
Doch. Aber es ging mir nicht um die durch das OS auferlegten Limits.

und warum hast Du die Ursprungsfrage nicht beantwortet? Andere haben das doch geschafft, bzw. sich darum bemueht.

Fragt sich nur, warum Du sowas machst.
Warum stellst du derart idiotische und abwegige Fragen, die du dir mit Hilfe der
Grundrechenarten auch selbst beantworten koenntest?

Mich hat die destruktive Ausrichtung Deines Verhaltensprofils halt ein wenig interessiert.

Gruss,
Ludger

[Christian Kruse]

Hallo Ludger,

Hi,

Wieviele Chat-Clients koennen von einem normal dimensionierten Server so bedient
werden?
Maximal 65536 (2^16). Das in TCP eingebaute Limit.
Lange vorher 'findet' man aber die Beschränkungen des Betriebssystems.
Das ist in der Tat richtig, ja, aber darum ging es mir ja nicht.
Dir ging es also nicht um die Bearbeitung der anfaenglichen Fragestellung.
Doch. Aber es ging mir nicht um die durch das OS auferlegten Limits.

und warum hast Du die Ursprungsfrage nicht beantwortet? Andere haben das doch geschafft,
bzw. sich darum bemueht.

Warum sollte ich? Sie ist trivial, das bisschen denken wirst du selber auch noch hinkriegen.

Fragt sich nur, warum Du sowas machst.
Warum stellst du derart idiotische und abwegige Fragen, die du dir mit Hilfe der
Grundrechenarten auch selbst beantworten koenntest?

Mich hat die destruktive Ausrichtung Deines Verhaltensprofils halt ein wenig interessiert.

Nein, nein, du hast da was falsch verstanden. Du haettest deine eigene Ausgangsfrage
problemlos mit ein bisschen Rechnen (Addition (Plus) und Multiplikatin (Mal) haetten
gereicht) problemlos selber beantworten koennen.

Grüße,
 CK

[Ludger]

Hi,

Wieviele Chat-Clients koennen von einem normal dimensionierten Server so bedient
werden?
Maximal 65536 (2^16). Das in TCP eingebaute Limit.
Lange vorher 'findet' man aber die Beschränkungen des Betriebssystems.
Das ist in der Tat richtig, ja, aber darum ging es mir ja nicht.
Dir ging es also nicht um die Bearbeitung der anfaenglichen Fragestellung.
Doch. Aber es ging mir nicht um die durch das OS auferlegten Limits.
und warum hast Du die Ursprungsfrage nicht beantwortet? Andere haben das doch geschafft,
bzw. sich darum bemueht.
Warum sollte ich? Sie ist trivial, das bisschen denken wirst du selber auch noch hinkriegen.

Ich glaube nicht, dass die Frage trivial zu beantorten ist. Du kannst diese Ansicht widerlegen indem Du die Frage beantwortest.

Nein, nein, du hast da was falsch verstanden. Du haettest deine eigene Ausgangsfrage
problemlos mit ein bisschen Rechnen (Addition (Plus) und Multiplikatin (Mal) haetten
gereicht) problemlos selber beantworten koennen.

Es ging hier nicht um die theoretisch moegliche noch von unetrschiedlichen Systemen unterstuetze Anzahl der IRC-Clients, sondern um die Anzahl, die ein heutzutage durchschnittlich dimensionierter Server noch handeln kann.

Gruss,
Ludger

[Christian Kruse]

Hallo Ludger,

Ich glaube nicht, dass die Frage trivial zu beantorten ist. Du kannst diese Ansicht
widerlegen indem Du die Frage beantwortest.

Liegt nicht in meiner Absicht. Fang selber an zu rechnen.

Nein, nein, du hast da was falsch verstanden. Du haettest deine eigene Ausgangsfrage
problemlos mit ein bisschen Rechnen (Addition (Plus) und Multiplikatin (Mal) haetten
gereicht) problemlos selber beantworten koennen.

Es ging hier nicht um die theoretisch moegliche noch von unetrschiedlichen Systemen
unterstuetze Anzahl der IRC-Clients, sondern um die Anzahl, die ein heutzutage
durchschnittlich dimensionierter Server noch handeln kann.

Es ging hier um die Frage, ob RSS-Chats Vorteile gegenueber IRC oder aehnlichen Protokollen
haetten.

Wie auch immer, ich habe keine Lust mehr mit dir zu spielen. EOT fuer mich.

Grüße,
 CK

[Henryk Plötz]

Moin,

Ich glaube nicht, dass die Frage trivial zu beantorten ist. Du kannst diese Ansicht widerlegen indem Du die Frage beantwortest.

Die Antwort ist in diesem Thread schon gefallen (die Schätzung lag IIRC bei 7 KiB für RSS/HTTP gegen 100 Bytes für IRC). Ich habe jetzt keine Lust die Nachricht rauszusuchen.

Es ging hier nicht um die theoretisch moegliche noch von unetrschiedlichen Systemen unterstuetze Anzahl der IRC-Clients, sondern um die Anzahl, die ein heutzutage durchschnittlich dimensionierter Server noch handeln kann.

Hier die Verbindungsmeldung eines bestimmten IRC-Servers als Stichprobe (du kannst doch englisch?):

--- There are 4109 users and 106779 invisible on 52 servers
--- 392 :IRC Operators online
--- 42751 :channels formed
--- I have 4016 clients and 1 servers
--- Current local  users: 4016  Max: 4029
--- Current global users: 110888  Max: 112251
--- Highest connection count: 4030 (4029 clients) (18965 connections received)

110888 User auf 52 Servern, 4016 User auf diesem einen Server.

[Ludger]

Hi,

110888 User auf 52 Servern, 4016 User auf diesem einen Server.

dann vielen Dank fuer die Nachricht. Eine andere Schaetzungen in diesem Thread legte eine praktische Grenze von ca. 250 User nahe.

Aeeh, die "technisch richtige" Antwort ist, glaube ich, fuer Entscheidungszwecke nicht relevant. Und war auch von mir nicht angefragt. Warum sich Christian Kruse da also so exponierte wage ich also nicht zu beurteilen.

Gruss,
Ludger

[at]

Hallo.

das bisschen denken wirst du selber auch noch hinkriegen.

Diese Unterstellung wirkt innerhalb dieses Threads geradezu grotesk.
MfG, at

[Tim Tepaße]

Hallo Ludger,

Nun, das geht nicht mit einem RSS Feed?

Nö. Ein Feed wird nur angefordert und weiterverarbeitet. Du mußt die Herkunft
von RSS bedenken, zuerst das News-Sammel-Portal von Netscape und dann die
jetzige Anwendung in Weblogs und Nachrichtenseiten.

(Weisst Du, ich arbeite in letzter Zeit mit SOAP und mit einigen
XML-basierten Schnittstellen - und da habe ich beim Trendy-RSS Feed auch den
Schreibzugriff irgendwie erwartet.

Siehe oben, das hängt mit der Herkunft von RSS zusammen. Natürlich kam dann
in der Weblogszene auch die Frage nach schreibenden Zugriff auf, daß man das
Weblogskript auf dem Server mit irgendeinem Client bedienen kann. Weswegen
dann unterschiedliche APIs gebastelt wurden, z.B. die Blogger API für den
Dienst blogger.com oder etwas genereller die MetaWeblog API. Beide arbeiten
mit XML-RPC, sollten Dir also vertraut vorkommen.

Zu RSS (bzw. den x unterschiedlichen, nicht kompatiblen Versionen von RSS)
gibt es ein Konkurrenzformat in der Entwicklung, Atom. Atom will sozusagen
RSS made right sein, gegenüber dern wackeligen Spezifikationen von RSS sind
sie auch auf einem guten Weg. Plus: Die Spezifikation geht gegenüber den
Spezifikationen von RSS einen offizielleren Weg, den als RFC durch die IETF.

Atom ist aber nicht nur ein Format zur Content Syndication wie RSS sondern
beinhaltet auch eine API zum Publizieren, die Atom API. Das einzige (außer
der Syntax), was sie von obigen APIs unterscheidet, ist, daß sie nicht über
eine weitere Zwischenebene (XML-RPC, SOAP) zwischen Inhalt und HTTP verfügt,
stattdessen nutzt sie das REST-Modell, das - simpel gesagt - XML-Daten über
HTTP unter der Ausnutzung aller HTTP-Verben ist. Ein vereinfachtes, aber
speziell dafür gedachtes XML gegenüber dem allgemeineren XML-RPC/SOAP.

Wenn Du allerdings all die diversen APIs und RSS Dir genauer anschaust,
wirst Du feststellen, daß die Formate nicht unbedingt unabhängig vom
Inhalt sind. Natürlich könnte man in der Theorie einen Chat darin abbilden,
besser geeignet sind die Syndication-Formate RSS x.x und Atom und die
Publishing APIs aber für ihren eigentlichen Einsatzzweck: Dem Zusammenfassen
und Publizieren von Inhalt, beispielsweise Nachrichtenartikeln.

Außerdem wäre das Daten-Overhead für einen Chat in diesem Fall viel zu
groß. Du müsstest für ein einfaches "Hallo" jede Menge Daten produzieren.

Mal ganz abgesehen von dieser Tatsache. Ich halte einen Chat über HTTP/RSS
für Schwachsinn.

Tim

[Ludger]

Hi,

[...] Wenn Du allerdings all die diversen APIs und RSS Dir genauer anschaust,
wirst Du feststellen, daß die Formate nicht unbedingt unabhängig vom
Inhalt sind. Natürlich könnte man in der Theorie einen Chat darin abbilden,
besser geeignet sind die Syndication-Formate RSS x.x und Atom und die
Publishing APIs aber für ihren eigentlichen Einsatzzweck: Dem Zusammenfassen
und Publizieren von Inhalt, beispielsweise Nachrichtenartikeln.

danke fuer die Erlaeuterungen. Ich habe mich bisher nur mit XML-Kommunikation (selbstgebastelt oder vorgefunden) bzw. SOAP-Kommunikation beschaeftigt, i.p. RSS / Atom bin ich mit Kenntnissen in die Diskussion gegangen, wie es sein muesste und nicht wie es ist, was natuerlich immer etwas riskant ist, aber in der Regel doch ueblicherweise Lerneffekte generiert.

Außerdem wäre das Daten-Overhead für einen Chat in diesem Fall viel zu
groß. Du müsstest für ein einfaches "Hallo" jede Menge Daten produzieren.

Ich lasse mich von dem Argument, dass 250 XML HTTP Chatclients sekuendlich mit spezifischen Reqeusts "pullen" auch etwas irritieren. Ich weiss nicht, ob das wirklich so viel ist. (Gibts bei uns Performanceprobleme, kommt der neue Server morgen ;-)

Was meinst Du: ist ein Pull-Abo nicht im Grundsatz immer einem "Push-Abo" vorzuziehen?

Mal ganz abgesehen von dieser Tatsache. Ich halte einen Chat über HTTP/RSS
für Schwachsinn.

Fuer ein Forum waere es aber OK, denke ich.   ;-)

Gruss,
Ludger

[Henryk Plötz]

Moin,

Ich lasse mich von dem Argument, dass 250 XML HTTP Chatclients sekuendlich mit spezifischen Reqeusts "pullen" auch etwas irritieren. Ich weiss nicht, ob das wirklich so viel ist. (Gibts bei uns Performanceprobleme, kommt der neue Server morgen ;-)

Was meinst Du: ist ein Pull-Abo nicht im Grundsatz immer einem "Push-Abo" vorzuziehen?

Nein, Pollen ist ist über 90% aller Fälle Mist, so auch in diesem.

Und deine Idee dass XML (in Form von RSS) über HTTP für Chats besser sein könnte als (irgendwas anderes, zum Beispiel HTML) über HTTP ist dermaßen abwegig, daß ich mir nicht vorstellen konnte dass du das Ernst gemeint hast. Aber das ist bei dir wohl ein grundlegendes Problem: Jedes mal wenn du 'abstrakt' wirst verlierst du die grundlegende Fähigkeit, addieren und multiplizieren zu können um dir eine Aufwandsabschätzung zu machen.

[Ludger]

Hi,

Was meinst Du: ist ein Pull-Abo nicht im Grundsatz immer einem "Push-Abo" vorzuziehen?

Nein, Pollen ist ist über 90% aller Fälle Mist, so auch in diesem.

Du gackerst hier wie ein Huhn und traegst nichts Substanzielles bei. Ich finde Deine Art ja ganz erfrischend und fuehle mich an meine Jugendzeiten erinnert, aber dennoch moechte ich Dich jetzt - trotz aller Sympathie - um einen Begruendungsversuch (mehr wirds ja wohl eher nicht werden, aber ich lasse mich gerne ueberraschen) bitten.

Und deine Idee dass XML (in Form von RSS) über HTTP für Chats besser sein könnte als (irgendwas anderes, zum Beispiel HTML) über HTTP ist dermaßen abwegig, daß ich mir nicht vorstellen konnte dass du das Ernst gemeint hast.

Auch hier gilt meine Einladung. (Aber lass Dir nicht von anderen helfen! ;-)

Aber das ist bei dir wohl ein grundlegendes Problem: Jedes mal wenn du 'abstrakt' wirst verlierst du die grundlegende Fähigkeit, addieren und multiplizieren zu können um dir eine Aufwandsabschätzung zu machen.

Mit Aufwandsschaetzungen (von der "Wir haben keine Zeit"-Truppe) wird man in der Regel keiner Sachfragenbearbeitung effizient dienen. Jedenfalls so lange, bis der Chef vom Chef auf einmal einen Brief schickt. Aber auch dann gilt wahrscheinlich fuer Typen wie Dich "Ich war aber nicht Schuld, dass ich enlassen worden bin.".

Aber noch bist Du nicht entlassen, also schreib mal was Vernuenftiges.

Gruss,
Ludger

[Raik]

Hallo, Ludger!

Du gackerst hier wie ein Huhn und traegst nichts Substanzielles bei. Ich finde Deine Art ja ganz erfrischend und fuehle mich an meine Jugendzeiten erinnert, aber dennoch moechte ich Dich jetzt - trotz aller Sympathie - um einen Begruendungsversuch (mehr wirds ja wohl eher nicht werden, aber ich lasse mich gerne ueberraschen) bitten.
[...]
Aber noch bist Du nicht entlassen, also schreib mal was Vernuenftiges.

sag mal, gehts noch?
WER ist hier in der pflicht, seine (wirren) theorien zu begründen? und wie lange willst du noch auf etwas rumreiten, von dem dir schon sehr ausführlich dargelegt wurde, warum es nicht effizient und deshalb unfug ist?

es geht dir, wie immer, mal wqieder nicht um die sache (denn sonst hättest du, wie es hier von JEDEM erwartet wird!!!), dazu schon längst eigene recherchen angestellt, sondern mal wieder um den streit um des streites willen. und damit der nicht aufhört, reitest du weiter auf deiner unbegründeten behauptung rum, anstatt selber mal fakten zu liefern zu seiner untermauerung.
schade nur, dass einige hier tatsächlich noch nach deinen stöckchen springen, statt dich ebenso darauf hinzuweisen, dass du selber sehr wenig zur antwort auf deine ausgangsfrage beiträgst.
du wiederholst seit stunden den gleichen zug. du weist aber, dass du damit im schach nach dem dritten mal automatisch verloren hast.

freundl. Grüsse aus Berlin, Raik

[Tim Tepaße]

Hallo Ludger,

Was meinst Du: ist ein Pull-Abo nicht im Grundsatz immer einem "Push-Abo"
vorzuziehen?

Nö. Garantiert nicht. Da Du heute etwas sehr auf den Schlauch zu stehen
scheinst (und andere unnötig anrotzt) mal eine Erklärung mit Bildern:

Stell Dir das ganze mal als Unterhaltung zwischen zwei Menschen vor. Ich
war mal so frei, das für Dich im IRC zu inszenieren. Hier das Push-Prinzip,
das sich hier dadurch auszeichnet, daß das zu Übermittelnde an den Client
(hier: »Eins«) gepusht wird.

Und nun das ganze als Pull-Abo. Hier muß der Client ständig neue Nachrichten
anfordern. Ich habe diese Anforderung hier mit dem »Hast Du mir etwas neues
zu sagen?« ausgedrückt, der Server antwortet dann entweder mit dem Neuen
oder mit nil. Und natürlich muß der Client diese Anforderung in regelmäßigen
Abständen wiederholen.

Da ist dann doch etwas mehr Verkehr auf der Leitung, oder?

Die Absurdität eines Chats über HTTP liegt nicht nur in HTTP oder irgendwelchen
XML-Strukturen. Es liegt in dem ständig neuen »Hast Du etwas neues für mich?«.
Bei anderen Anwendungen, beispielweise Content Syndication mit RSS, ist das
nicht so schlimm, da ist nicht so oft etwas Neues vorhanden, so daß man den
Zeitraum zwischen den Anforderungen sehr viel länger gestalten kann. Bei
einem Chat ist das schwachsinnig.

Tim

[Ludger]

Hi,

Was meinst Du: ist ein Pull-Abo nicht im Grundsatz immer einem "Push-Abo"
vorzuziehen?

Nö. Garantiert nicht. [...]

ich werde dennoch versuchen einige Pro-Argumente einzupflechten.

Da ist dann doch etwas mehr Verkehr auf der Leitung, oder?

"Das haengt nur vom Traffic ab, der die permanente Verbindung verursacht."

Die Absurdität eines Chats über HTTP liegt nicht nur in HTTP oder irgendwelchen
XML-Strukturen. Es liegt in dem ständig neuen »Hast Du etwas neues für mich?«.
[...] Bei
einem Chat ist das schwachsinnig.

Wenn wir uns einig sind, dass man geschaeftlogisch relevante Sachverhalte in IT nachbaut, um Prozesse und Projekte der Geschaeftswelt nachzubilden und dann zu unterstuetzen, koennen wir fortsetzen.
(Streng genommen sind auch nur potentiell geschaeftslogisch relevante Sachverhalte praeventiv nachzubauaen, aber das moechte ich an dieser Stelle nicht weiter ausfuehren.)

Die o.g. Sachverhalte vorausgesetzt koennen wir nun versuchen uns Schritt fuer Schritt der Sache weiter anzunaehern:
Was wird also nachgebaut? - Im Prinzip so etwas wie ein zuverlaessig fortschreitender Zeitungsversand neuester Nachrichten.

Und nun sind "auf einmal" die Interessen der Clients und Server zu beruecksichtigen.

Betrachten wir mal den Server: will versenden, will ein Ereignis ausgeloest sehen bei Fehlsendung...

Und der Client: erwartet Lieferung, loest geschaeftslogisch ein Ereignis aus, wenn Daten nicht geliefert...

Diese oberflaechliche Betrachtung genuegt, um feststellen zu koennen, dass der Client der "Main-Player" ist, also unter allen Umstaenden auf Nicht-Lieferung zu reagieren hat. (Wir sprechen hier beispielsweise ueber Auskuenfte bzgl. der Bonitaet eines Finzanzierungsanfragenden oder ueber Daten, die eine Finanzbuchhaltung erwartet oder um Informationen fuer das Team, das die Refinanzierung verwaltet oder ...)
Der GAU tritt also clientseitig auf, was bedingt, dass eben dort Code zur Ausfuehrung gelangen (ein "Ereignis" eintritt) muss, der unabhaengig vom Verbindungserfolg der Komponenten sicherzustellen hat, dass Mitarbeiter letztlich zur Tat schreiten, wenn die "Systeme" versagen.

Nun stellt sich also die Frage, wie das o.g. sichergestellt werden kann, wenn die o.g. Systeme nicht bereitstehen und die Datenuebertragung durch einen "Push" angestossen wird. Antwort: NULL

Daraus folgt, dass geschaeftslogisch erfoderlicher Code eben beim Abnehmer (Client) zur Ausfuehrung zu gelangen hat, da ansonsten "der Baer tanzt".

So ist die Realitatet. Wenn bei uns einer schlaeft, kann der nicht mal eben so ganz locker auf die Nichtverfuegbarkeit der Systeme verweisen, d.h. also ein Server-Push (bzw. Server-Pull) ist auf Erfolg zu pruefen.

Da kann man dann nicht sagen, dass nicht geliefert worden ist (und das nicht bemerkt worden ist). Das kostet (wohlverdient) dann die Ruebe.

(Ich koennte das natuerlich, genuegend Zeit vorausgesetzt, zu einem System weiterentwickeln, bisweilen bitte ich um Akzeptanz der Vorlieferung. - Feinspezifisch erlaeutern kann man ja immer noch spaeter.   ;-)

Gruss,
Ludger

[Andreas Korthaus]

Hi!

[...] Bei einem Chat ist das schwachsinnig.

(Wir sprechen hier beispielsweise ueber Auskuenfte bzgl. der Bonitaet eines Finzanzierungsanfragenden oder ueber Daten, die eine Finanzbuchhaltung erwartet oder um Informationen fuer das Team, das die Refinanzierung verwaltet oder ...)

Ach so...

Grüße
Andreas

[Ludger]

Hi,

Ach so...

es ging mehr um Server-Pull und Server-Push.

Gruss,
Ludger

[Andreas Korthaus]

Hi!

Ach so...

es ging mehr um Server-Pull und Server-Push.

Schonmal auf die Idee gekommen, dass sich das nicht verallgemeinern lässt? Nicht umsonst gibt es mehr als ein Kommunikations-Protokoll: http://www.ietf.org/iesg/1rfc_index.txt. Die haben alle ihre Vor- und Nachteile.

Grüße
Andreas

[Ludger]

Hi,

Schonmal auf die Idee gekommen, dass sich das nicht verallgemeinern lässt? Nicht umsonst gibt es mehr als ein Kommunikations-Protokoll: http://www.ietf.org/iesg/1rfc_index.txt. Die haben alle ihre Vor- und Nachteile.

danke, koennen wir das etwas zurueckstellen, aeeh, bis Tim sich geaeussert hat (ich hoffe, dass das nicht zu vernichtend ausfaellt ;-)   - Studis sind aber in der Regel (Ausnhamen mag es geben ;-) schlau)

Gruss,
Ludger

[Ludger]

Hi,

es ging mehr um Server-Pull und Server-Push.

Schonmal auf die Idee gekommen, dass sich das nicht verallgemeinern lässt? Nicht umsonst gibt es mehr als ein Kommunikations-Protokoll: http://www.ietf.org/iesg/1rfc_index.txt. Die haben alle ihre Vor- und Nachteile.

ja, so ist die Lehre. Aber was ich in der Praxis sehe ist, dass wenn die Daten nicht uebermittelt worden sind, beim Client den Fehler bearbeitender Code ausgeloest wird (oder eskaliert wird ;-). Also bin ich ueber die Jahre zum Server-Puller geworden.

Gruss,
Ludger

[Tim Tepaße]

Hallo Ludger,

Wenn wir uns einig sind, dass man geschaeftlogisch relevante Sachverhalte
in IT nachbaut, um Prozesse und Projekte der Geschaeftswelt nachzubilden
und dann zu unterstuetzen, koennen wir fortsetzen.

Im Prinizip könnten wir dann ja aufhören, denn einig mit Dir bin ich mir da
schon nicht. Ich probier es trotzdem noch mal.

Wieso reitest Du nur auf geschäftlogischen Prozessen rum? Ist das irgendeine
Betriebsblindheit von Dir, die Dich blind für Die Realität [tm] macht? Es
gibt doch nicht nur geschäftslogische Prozesse, Chat ist nicht nur ein
geschäftslogischer Prozess, sondern ein sehr viel allgemeinerer Prozess,
Kommunikation, Geschwätz.

Was wird also nachgebaut? - Im Prinzip so etwas wie ein zuverlaessig
fortschreitender Zeitungsversand neuester Nachrichten.

Ein Chat ist für Dich also ein Zeitungsversand? Ah ja. Man merkt wirklich,
daß Du wenig Chaterfahrung hast. ;o)

Und der Client: erwartet Lieferung, loest geschaeftslogisch ein Ereignis
aus, wenn Daten nicht geliefert...

Du verrennst Dich in Deinen geschäftslogischen Prozessen. Nimm eine sehr
viel leichtere Analogie: die Kommunikation zwischen zwei Menschen. Du bist
jetzt mal der Client und sitzt irgendjemanden gegenüber, der »Server« auf
der Brust stehen hat, ihr beide schweigt euch an. Erwartest Du jetzt im
Normalfall eine »Lieferung«? Und wenn ja, woher weist Du was davon? Der
Server zuckt nicht mal mit dem Mundwinkel, es gibt keine Anzeichen dafür,
ob er nun etwas sagen (»liefern«) oder weiterhin schweigen will. Du kannst
das gar nicht wissen, Du kannst gar kein Ereignis auslösen, weil Dir das
Wissen fehlt.

(Wir sprechen hier beispielsweise ueber Auskuenfte bzgl. der Bonitaet
eines Finzanzierungsanfragenden oder ueber Daten, die eine
Finanzbuchhaltung erwartet oder um Informationen fuer das Team, das die
Refinanzierung verwaltet oder ...)

Du sprichst. Wir nicht. Wir reden über den allgemeinen Fall Chat, Du
offenbar nicht. Warum nicht? Ist Dir das Konzept so unvertraut, denkst
Du nur so eng?

Daraus folgt, dass geschaeftslogisch erfoderlicher Code eben beim Abnehmer
(Client) zur Ausfuehrung zu gelangen hat, da ansonsten "der Baer tanzt".

Ja, geschäftslogischer Code. In der Anwendung »Chat« ist das meistens
ziemlich wurst.

... bisweilen bitte ich um Akzeptanz der Vorlieferung.

Du beweist sehr viel Phantasie bei Deinem Ausweichen auf Spezialfälle,
ja. Und? Du hast das Thema angestoßen, ob man einen Chat auch über HTTP
implementieren kann, wieso bleibst Du nicht bei diesem Thema? Muß ich
Dir wieder Bildchen malen, hast Du immer noch einen schlechten Tag, zu
wenig frische Luft, Bauchschmerzen? ;o)

Tim

[Ludger]

Hi,

Du beweist sehr viel Phantasie bei Deinem Ausweichen auf Spezialfälle,
ja. Und? Du hast das Thema angestoßen, ob man einen Chat auch über HTTP
implementieren kann, wieso bleibst Du nicht bei diesem Thema? Muß ich
Dir wieder Bildchen malen, hast Du immer noch einen schlechten Tag, zu
wenig frische Luft, Bauchschmerzen? ;o)

ich hatte bereits versucht "Dr." Andreas Korthaus auf die von mir vollzogene Themenaenderung hinzuweisen. (Ich denke zudem, dass das konzeptionell abgedeckt und gewuenscht ist.) Nein, es schien mir klar zu sein, dass meine Meinungsaeusserung im Kontext "Server-Pull v. Server-Push" zu interpretieren war.

Sollte das nicht hinreichend klar gewesen sein bitte ich alle kritischen Kraefte ausnahmslos um Tolereanz.

Gruss,
Ludger

[Andreas Korthaus]

Hi!

[...] "Dr." Andreas Korthaus [...]

Danke für die Blumen, aber der Titel steht mir leider (noch?) nicht zu.

Grüße
Andreas

[Ludger]

Hi,

Wenn wir uns einig sind, dass man geschaeftlogisch relevante Sachverhalte
in IT nachbaut, um Prozesse und Projekte der Geschaeftswelt nachzubilden
und dann zu unterstuetzen, koennen wir fortsetzen.

Im Prinizip könnten wir dann ja aufhören, denn einig mit Dir bin ich mir da
schon nicht. Ich probier es trotzdem noch mal.

ich hatte die Geschaeftswelt natuerlich sehr weit gefasst. So ist auch dieses Forum nach meiner Definition "Geschaeft ist, wenn Leute zusammenarbeiten" ein Geschaeft. Geschaefte sind also fuer mich per se etwas Gutes, eben Kooperationsverhaeltnisse. Und Kooperationsverhaeltnisse werden mit Software unterstuetzt.

Aeeh, Du hast jetzt noch ein bisschen auf der HTTP-XML Chatclientgeschichte herumgehackt. Ich denke, dass Deine Argumente OK sind und gegen eine Umsetzung zur heutigen Zeit sprechen. Auch trendige RSS Feed-Technologie unterstuetzt die Idee nicht, der von Dir genannte "Nachfolger" Atom (ich hoffe, dass es den wirklich gibt, geprueft habe ich das noch nicht ;-) wird keinen sexy HTTP-XML Chatclient erlauben, zumindest waere es ein Trafficbulle und zurzeit versucht man ja noch Traffic von einigen K bis M Byte zu vermeiden.

Also, ich hatte das Thema schon ein wenig verlassen und darum Fragen wie "Was folgt den Browsern nach? (eher indirekt)" bzw. "Pull ist gut, Push ist boese? (schon direkter)" behandelt. Zugegebenermassen Brainstorming (auch, wenn ich natuerlich daran glaube was ich schreibe).

Gruss,
Ludger

[Tim Tepaße]

Hallo Ludger,

ich hatte die Geschaeftswelt natuerlich sehr weit gefasst. So ist auch
dieses Forum nach meiner Definition "Geschaeft ist, wenn Leute
zusammenarbeiten" ein Geschaeft.

Ich würde das eher als Kommunikation bezeichnen. Ein »Geschäft« würde ich
demzufolge dann als Spezialfall der Kommunikation bezeichnen, in dem dann
Vorraussetzungen wie (Ausfall-) Sicherheit zutrefen müßten.

Aeeh, Du hast jetzt noch ein bisschen auf der HTTP-XML Chatclientgeschichte
herumgehackt.

Eher auf dem Pull-Prinzip, wovon HTTP natürlich nur eine Anwendung ist. XML
ist mir da relativ wurst, wobei ich auch bei einer hypothetischen HTTP-Variante
eines Chats noch nicht sehe, weswegen man da die Daten noch mit noch mehr
Markup aufpropfen muß.

zumindest waere es ein Trafficbulle und zurzeit versucht man ja noch Traffic
von einigen K bis M Byte zu vermeiden.

Also ich sehe das Prinzip der Sparsamkeit noch lange nicht wegfallen. Warum
auch?

Fragen wie "Was folgt den Browsern nach? (eher indirekt)"

Wobei das bei RSS natürlich nahe liegt, RSS-Reader greifen aufs Web zu
ohne Browser zu sein. Es gibt zwar Varianten, RSS in Browser zu integrieren,
dies aber nur ins Bookmarksystem (Omniweb, Firefox), was ich für etwas
kurz gedacht halte. Safari 2.0 wird das anders handhaben, wie sich das
in der Praxis anfühlen wird, wird man im 2. Quartal 2005 sehen.

Es gibt auch noch weitere Ideen, RSS zu nutzen. Manche plädieren für die
Ablösung von Newsletter als RSS, seit einiger Zeit ist Podcast im Gespräch,
was praktisch Musikversand von wemauchimmer ist. MP3s werden da in RSS
eingebettet, es wird interessant sein, die kommenden speziell darauf
ausgerichteten Anwendungen zu betrachten.

(auch, wenn ich natuerlich daran glaube was ich schreibe).

Oh..

Tim

[Thomas J.S.]

Hallo,

Aeeh, Du hast jetzt noch ein bisschen auf der HTTP-XML Chatclientgeschichte herumgehackt.

Wenn es dir wirklich so wichtig ist, kannst du ja folgendes für deine XML-RPCs verwenden/versuchen (was aber trotzdem noch seehr lange keinen Chat ermöglicht):
http://mozblog.mozdev.org/nsXmlRpcClient.js ;)

Grüße
Thomas

[Gunnar Bittersmann]

wackeligen Spezifikationen von RSS

Tim,
Was "wackelt" an RSS 1.0? Ist doch sauberes RDF/XML. Wie vom W3C zu erwarten ist.
Gunnar

[Tim Tepaße]

Hallo Gunner,

Was "wackelt" an RSS 1.0? Ist doch sauberes RDF/XML. Wie vom W3C zu erwarten ist.

Das ging auch eher in die Richtung RSS 2.0 und dessen 0.9x Vorgänger. Wobei
mir das RDF in RSS 1.0 etwas zuviel ist, da stimme ich dem simplen Ansatz von
Dave Winer mehr zu. (Soweit ich weiß, wurde RSS 1.0 auch nicht unbedingt vom
W3C entwickelt sondern nur von einer Gruppe, die aus dem W3C hervorging, was
auch immer darunter zu verstehen ist)

Tim

[Gunnar Bittersmann]

Hallo Tim,

Wobei mir das RDF in RSS 1.0 etwas zuviel ist

Wenn man nicht gerade einen Texteditor benutzt, um das RSS zu schreiben, sollte das doch egal sein.

Mit RDF kann man sehr schön Dinge (was auch immer) beschreiben.

Soweit ich weiß, wurde RSS 1.0 auch nicht unbedingt vom
W3C entwickelt sondern nur von einer Gruppe, die aus dem W3C hervorging

Das sollte für alle Entwicklungen des W3C gelten. Ich glaub nicht, dass alle W3C-Mitglieder auf einer Generalversammlung über CSS, XHTML, RDF, ... beraten.

Gruß,
Gunnar

[Tim Tepaße]

Hallo Gunnar,

Wenn man nicht gerade einen Texteditor benutzt, um das RSS zu schreiben,
sollte das doch egal sein.

Genau das habe ich mal eine Zeitlang gemacht. Allerdings RSS 2.0. ;)

Das sollte für alle Entwicklungen des W3C gelten. Ich glaub nicht, dass alle
W3C-Mitglieder auf einer Generalversammlung über CSS, XHTML, RDF, ... beraten.

Nö, dafür gibt es ja auch Working Groups. Was ich eher meinte: RSS 1.0 ist
keine offizielle Recommondation des W3Cs sondern eher ein »privater Standard«,
die Leute, die das entwickelt haben, sind zwar als W3C-nah zu bezeichnen,
haben sich aber mehr über die Opposition zu Userland/Dave Winer und der
Nähe zum RDF-Modell (wie in RSS 0.9 von Netscape) identifiziert. Die
Entwicklung fand auch nicht über das W3C sondern über eine Yahoo! eGroup
und dessen Mailingliste statt.

Tim

[Tim Tepaße]

Hallo Thomas,

1. Du willst sicherlich nicht immer die ganze RSS-Datei laden. Das müsste
   aber dein Programm, eben wie ein Feed-Reader das auch macht.

»Im Prinzip« spräche nix dagegen, daß HTTP-Client, hier der RSS-Reader und
Server über HTTP aushandeln, ob sich etwas seit dem letzten Abruf des RSS-Feeds
etwas geändert hat und der Server dann entsprechend den Feed anpasst.
Allerdings weiß ich in der Praxis kaum einem RSS-Reader, der das kann;
selbst Gzip-Kodierung soll manchmal für Probleme sorgen. Und es wäre immer
noch viel zu viel Overhead für einen Chat. ;)

Tim

[fastix®]

Moin!

also, noch mal ganz verstaendlich, kann man einen Chat per RSS Feed und "Pull-Datenabo" effizient realisieren oder nicht?

Das ist komplett ineffizient. Ich habe selbst mal einen Chat in PHP/HTML/JS gschrieben. Der muss fast alles benutzen, was "böse[tm]" ist, um einigermaßen effizient zu arbeiten.

Meiner brauchte also Frames, Javascript und aller paar Sekunden einen Request auf den Server, was  Traffic erzeugt. Allerdings ist es mir gelungen nicht immer wieder die komplette Seite zu laden, sondern nur den Timestamp der letzten Änderung abzufragen und bei Änderung ca. 100 Zeilen Text zu holen. Sicherlich nichts für Chats mit vielen Teilnehmern, aber 20 hat der schon mal sehr gut ausgehalten.

Das Problem dabei ist: (javabasierte) IRC- Chats sind frei verfügbar, der Benutzer kann aber auch seine gewohnte IRC-Software benutzen, das ist sein Vorteil. Insofern fragt es sich, ob es sich bei Projekten, die ja wachsen _sollen_, lohnt mit einer solchen Krücke zu starten.

Bei Projekten, die klein bleiben. wie z.B. privaten Homepages geht das sicher. Aber, was wenn sie doch wachsen? Doppelte Entwicklungsarbeit?

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Johannes Zeller]

Hallo fastix,

Sicherlich nichts für Chats mit vielen Teilnehmern, aber 20 hat der schon mal sehr gut ausgehalten.

Es gibt aber auch »funktionierende« HTTP-Chats, die mit entsprechend vielen Teilnehmern klar kommen (z.B. die Heise-Themenchats).

Das Problem dabei ist: (javabasierte) IRC- Chats sind frei verfügbar, der Benutzer kann aber auch seine gewohnte IRC-Software benutzen, das ist sein Vorteil. Insofern fragt es sich, ob es sich bei Projekten, die ja wachsen _sollen_, lohnt mit einer solchen Krücke zu starten.

Bei Projekten, die klein bleiben. wie z.B. privaten Homepages geht das sicher. Aber, was wenn sie doch wachsen? Doppelte Entwicklungsarbeit?

Ich denke, die Entscheidung für das Eine oder Andere sollte eher von der Zielgruppe abhängen. Normalerweise bevorzuge ich einen IRC-Chat, aber wenn davon auszugehen ist, dass ein größerer Teil der Benutzer kein Java hat und es wahrscheinlich auch keine Leute mit IRC-Clients dabei sind, wird ein Web-Chat wahrscheinlich trotz der Nachteile die bessere Wahl sein.

Schöne Grüße,

Johannes

[Henryk Plötz]

Moin,

Es gibt aber auch »funktionierende« HTTP-Chats, die mit entsprechend vielen Teilnehmern klar kommen (z.B. die Heise-Themenchats).

Wobei der Heise-Chat die unzulässige Annahme macht, man würde über HTTP streamen können. Der funktioniert also nicht, der tut nur äusserst effektiv so, als würde er funktionieren. Das fliegt einem spätestens um die Ohren wenn man ein etwas komplexeres Proxy/Gateway-Setup hat. Fastix' Implementation hat das Problem nicht, soweit ich seine Ausführungen verstanden habe.

[Johannes Zeller]

Hallo Henryk,

Es gibt aber auch »funktionierende« HTTP-Chats, die mit entsprechend vielen Teilnehmern klar kommen (z.B. die Heise-Themenchats).

Wobei der Heise-Chat die unzulässige Annahme macht, man würde über HTTP streamen können. Der funktioniert also nicht, der tut nur äusserst effektiv so, als würde er funktionieren.

Es hatte schon seinen Sinn, dass ich »funktionierende« in Anführungszeichen geschrieben hab ;-)

Das fliegt einem spätestens um die Ohren wenn man ein etwas komplexeres Proxy/Gateway-Setup hat. Fastix' Implementation hat das Problem nicht, soweit ich seine Ausführungen verstanden habe.

Aber dafür andere. Aber ich wiederhole mich, glaube ich, wenn ich sage, dass Chats auf Webseiten immer nur die Wahl der Lösung, die im Einzelfall am wenigstens Probleme darstellt, ist.

Schöne Grüße,

Johannes

[Ludger]

Hi,

also, noch mal ganz verstaendlich, kann man einen Chat per RSS Feed und "Pull-Datenabo" effizient realisieren oder nicht?

Das ist komplett ineffizient. Ich habe selbst mal einen Chat in PHP/HTML/JS gschrieben. Der muss fast alles benutzen, was "böse[tm]" ist, um einigermaßen effizient zu arbeiten.

_das_ war aber nicht gemeint. Meine These war ja gerade dass "HTTP+HTML" fuer den Chatbetrieb nicht taugen, "HTTP+XMLClient" aber sehr wohl. Also die "revolutionaere" These, dass HTML den Chat verunmoeglicht, nicht HTTP.   ;-)
Aber es war eine Idee zu spaeter Stunde, was solche Ideen dann immer angreifbar macht (zumindest hier ;-).

Meiner brauchte also Frames, Javascript und aller paar Sekunden einen Request auf den Server, was  Traffic erzeugt. Allerdings ist es mir gelungen nicht immer wieder die komplette Seite zu laden, sondern nur den Timestamp der letzten Änderung abzufragen und bei Änderung ca. 100 Zeilen Text zu holen. Sicherlich nichts für Chats mit vielen Teilnehmern, aber 20 hat der schon mal sehr gut ausgehalten.

Bravo! Aber schoen isses nicht.

Das Problem dabei ist: (javabasierte) IRC- Chats sind frei verfügbar, der Benutzer kann aber auch seine gewohnte IRC-Software benutzen, das ist sein Vorteil. Insofern fragt es sich, ob es sich bei Projekten, die ja wachsen _sollen_, lohnt mit einer solchen Krücke zu starten.

Ja, hier eben der revolutionaere Ansatz IRC-Chats zu verbessern. Das kann nur gelingen, wenn der skizzierte HTTP XML Chatclient leistungsfaehiger ist als die IRC-Varianten.

Gruss,
Ludger

[Raik]

Hallo, Ludger!

Wir haetten da ...
ja, sowas verstehen hier anscheinend nur noch ein paar Leute.   :-(

was gibts da (nicht ?) zu verstehen?

würdest du dich bitte zuerst darüber informieren, wie ein verbindungsaufbau über http abläuft und welcher overhead dabei gegenüber einer permanenten verbindung entsteht, bevor du hier thesen in die welt setzt? auch von dir wird (wie von jedem anderen) erwartet, dass du dir zumindest erst mal die grundlagener arbeitest, bevor du hier fragen stellst. besonders, wenn du diese auf grundlage ungeprüfter, falscher annahmen formulierst.

Ein Plaedoyer gegen HTTP?   ;-)

nicht ablenken! was haben deine recherchen zum traffic eines wiederholten verbindungsaufbaus gegenüber einer permanenten verbindung ergeben?
damit kannst du dir deine frage selber beantworten.

freundl. Grüsse aus Berlin, Raik

[Henryk Plötz]

Moin,

Wobei man der Korrektheit halber dazu sagen müsste, daß man einen Chat oder ein Forum theoretisch natürlich auch als RSS/XML-Feed anbieten könnte, um diesen in eine andere Seite einzubinden.

Auja, wenn ich mal ganz viel Langeweile habe baue ich einen IRC-nach-RSS-Konverter. Gibt es eigentlich einen Feedreader der ein Refresh-Interval im Sekundenbereich unterstützt? ;-)

[at]

Hallo.

Auja, wenn ich mal ganz viel Langeweile habe baue ich einen IRC-nach-RSS-Konverter.

Derweil kann man sich ja mit den bereits vorhandenen behelfen.

Gibt es eigentlich einen Feedreader der ein Refresh-Interval im Sekundenbereich unterstützt? ;-)

Vermutlich jeder, der im Quellcode vorliegt.
MfG, at

[Thomas J.S.]

Hallo,

Wobei man der Korrektheit halber dazu sagen müsste, daß man [...] ein Forum theoretisch natürlich auch als RSS/XML-Feed anbieten könnte,

http://forum.de.selfhtml.org/rss/

Bei einem Chat gibt sowas keinen Sinn, da erstens RSS ja als Datei auch geschrieben wird und weil es eben über HTTP läuft und bei so vielen Requests von einem IP müsste der Server eine DoS-Attacke vermuten, was auch gegen HTML-Chats spricht.

Grüße
Thomas

[Ludger]

Hi,

Wobei man der Korrektheit halber dazu sagen müsste, daß man [...] ein Forum theoretisch natürlich auch als RSS/XML-Feed anbieten könnte,

http://forum.de.selfhtml.org/rss/

Bei einem Chat gibt sowas keinen Sinn, da erstens RSS ja als Datei auch geschrieben wird und weil es eben über HTTP läuft und bei so vielen Requests von einem IP müsste der Server eine DoS-Attacke vermuten, was auch gegen HTML-Chats spricht.

die Daten koennten ja in einem Sicherheitskontext inkrementell uebertragen werden. Geht das mit einem RSS Feed nicht? (DOS-Attacken waeren dann auch ein eher kleines Problem.)

Gruss,
Ludger

[Thomas J.S.]

Hallo,

die Daten koennten ja in einem Sicherheitskontext inkrementell uebertragen werden.

Klar geht das. Das heisst dann Sandbox und läuft mit Java.

Grüße
Thomas

[Henryk Plötz]

Moin,

[Chat]
die Daten koennten ja in einem Sicherheitskontext inkrementell uebertragen werden.

Klar geht das. Das heisst dann Sandbox und läuft mit Java.

Du meinst http://aktuell.de.selfhtml.org/live/chat.htm?

SCNR