Intermud4

3 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Stefan Riemer

ungelesen,
06.09.2003, 03:41:4506.09.03
an
Hi,

ich weiss nicht inwiefern die Leser hier Interesse daran haben, aber ein
Artikel tut allemal nicht weh :) Es gibt eine inzwischen schon recht
ansehnliche Diskussion über einen Ersatz für Intermud2 und 3. Details sind
zu finden auf http://ff.mud.de/wiki/bin/view/Mud/InterMud4
Da drumherum ist übrigens auch das bereits erwähnte de.alt.mud-Wiki, was
durchaus noch ein paar Beiträge verträgt. :-)

Tschau sagt Stefan
--
In RL: peng.ff_at_gmx.de
In VL; Peng@FinalFrontier, try telnet://ff.mud.de

Stephan 'Invisible' Weinberger

ungelesen,
06.09.2003, 04:27:1006.09.03
an
* Stefan Riemer <usene...@gmx.net> wrote:
>
> ich weiss nicht inwiefern die Leser hier Interesse daran haben, aber ein
> Artikel tut allemal nicht weh :) Es gibt eine inzwischen schon recht
> ansehnliche Diskussion über einen Ersatz für Intermud2 und 3. Details
> sind zu finden auf http://ff.mud.de/wiki/bin/view/Mud/InterMud4
> Da drumherum ist übrigens auch das bereits erwähnte de.alt.mud-Wiki, was
> durchaus noch ein paar Beiträge verträgt. :-)

Was, und ich hab garnix davon mitgekriegt? :-)

Aus dem letzten Versuch (MRP, http://al.mud.de/foren/) ist ja leider nix
geworden...

Die Verwendung von Jabber/XML klingt auf jeden Fall aeusserst
interessant, so ist es zumindest mal wesentlich einfacher geeignete
Router zu finden bzw. aufzusetzen. Ausserdem ist XML natuerlich von Haus
aus leicht erweiterbar... ja, klingt wirklich gut.

Was mir noch ein wenig abgeht ist die Moeglichkeit einer Verschluesselung
(z.B. fuer "tell"). Auch sollte irgendwie ausgeschlossen werden, dass von
aussen ein MUD "gefaelscht" werden kann... Ich weis, diese Features
bietet IM2 auch nicht, aber wenn man schon dabei ist ein neues Protokoll
zu entwerfen...

--
cu mail: invi...@xover.mud.at
Invisible@Beutelland www: http://invisible.priv.at
The choices we make, not the chances we take, determine our destiny.

Erhard Sanio

ungelesen,
06.09.2003, 16:55:5806.09.03
an
Stephan 'Invisible' Weinberger schrieb:

> * Stefan Riemer <usene...@gmx.net> wrote:
> > ich weiss nicht inwiefern die Leser hier Interesse daran haben, aber ein
> > Artikel tut allemal nicht weh :) Es gibt eine inzwischen schon recht
> > ansehnliche Diskussion über einen Ersatz für Intermud2 und 3. Details
> > sind zu finden auf http://ff.mud.de/wiki/bin/view/Mud/InterMud4
> > Da drumherum ist übrigens auch das bereits erwähnte de.alt.mud-Wiki, was
> > durchaus noch ein paar Beiträge verträgt. :-)

> Was, und ich hab garnix davon mitgekriegt? :-)

..
> Die Verwendung von Jabber/XML klingt auf jeden Fall aeusserst
> interessant, so ist es zumindest mal wesentlich einfacher geeignete
> Router zu finden bzw. aufzusetzen. Ausserdem ist XML natuerlich von Haus
> aus leicht erweiterbar... ja, klingt wirklich gut.

..

Hmm, mal eine Frage eines doofen Users - was soll denn das neue
Intermudprotokoll bringen? Vereinheitlichungen und Erleichterungen
der Arbeit fuer die Programmierer (was ja ok ist) oder auch etwas
fuer die Nutzergemeinde?

Aus meiner Froschperspektive hat der Uebergang von Intermud 1 nach 2
nicht so sehr viel gebracht - ok, ich glaube, Anfang der neunziger
ging 'tell <user>@<mud>' noch nicht, von Intermud-Channels gar nicht
zu reden. Aber spaeter ging das schon unter intermud 1, meine ich.

Wird es, wenn die Kommunikation mittels xml-Containern ablaufen kann,
neue Features geben? Das waere fuer den Normalspieler von Interesse.

regards, es

--
Wenn ich tausend Zungen und tausend Muender haette, eine erzene Stimme,
koennte ich doch alle Erscheinungen von Bloedheit nicht anfuehren oder alle
Namen, unter denen Torheit auftritt, aufzaehlen (Erasmus von Rotterdam,1509)

Stephan 'Invisible' Weinberger

ungelesen,
06.09.2003, 17:22:1006.09.03
an
* Erhard Sanio <erhard...@gmx.net> wrote:

> Hmm, mal eine Frage eines doofen Users - was soll denn das neue
> Intermudprotokoll bringen?

Fuer den User aendert sich hauptsaechlich ein Punkt: Das Teil wird
zuverlaessiger.
IM1 und 2 basieren auf UDP. Dabei werden die Pakete einfach ins Netz
"geworfen", wenn sie ankommen hat man Glueck gehabt, Kontrolle gibt es
keine. Das Ergebnis: "tell"s die nicht ankommen, tw. fehlende Nachrichten
auf den Channels, ...
Jetzt koennte man natuerlich einfach IM2 auf TCP umbauen, aber das
Protokoll hat noch ein paar andere Schwaechen, sodass man besser gleich
was "ordentliches" entwirft.

Das bestehende (und noch immer von den meisten MUDs _nicht_
unterstuetzte) IM3 basiert bereits auf TCP, dabei hat man automatisch
eine Flusskontrolle, sprich man kann sich sicher sein, dass das Paket
auch wirklich beim Empfaenger ankommt (oder man bekommt eine
Fehlermeldung). Leider sind bei IM3 die Router (eigentlich _der_ Router,
oder gibt es inzwischen einen zweiten?) nicht OpenSource, weswegen eben
schon laenger ueber Nachfolgeprotokolle diskutiert wird (siehe den von
mir erwaehnten Link) und weswegen es eben noch nicht so verbreitet ist.

Darueberhinaus hat man bei IM2 das Problem, dass jedes einzelne MUD z.B.
eine Channel-Message an ALLE anderen MUDs senden muss. Jedes MUD muss
also eine moeglichst vollstaendige Liste aller MUDs inkl. aktueller IP
verwalten. Dass das nicht imemr ganz reibungslos funktioniert merkt man
regelmaessig auf den Kanaelen, wenn einzelne MUDs nicht alles mitkriegen.

> Wird es, wenn die Kommunikation mittels xml-Containern ablaufen kann,
> neue Features geben? Das waere fuer den Normalspieler von Interesse.

Obiges ist IMHO fuer den normalen Spieler durchaus schon eine bedeutende
Verbesserung. Aber wenn Dir noch weitere Sachen einfallen: XML ist leicht
erweiterbar, ohne darunterliegende Schichten anpassen zu muessen.

Carlo v. Loesch

ungelesen,
08.09.2003, 07:46:2408.09.03
an
Stephan 'Invisible' Weinberger wrote:
> IM1 und 2 basieren auf UDP. Dabei werden die Pakete einfach ins Netz
> "geworfen", wenn sie ankommen hat man Glueck gehabt, Kontrolle gibt es
> keine. Das Ergebnis: "tell"s die nicht ankommen, tw. fehlende Nachrichten
> auf den Channels, ...

jahrelanges udp broadcasting.. da hat man schonmal paketausfälle,
sicher.. und wenn man dann nicht einmal die messages numeriert, kann man
sie auch nicht kontrollieren etc. ja ja schon abenteuerlich so.
warum wurden die packets nicht einfach numeriert?

> Leider sind bei IM3 die Router (eigentlich _der_ Router,
> oder gibt es inzwischen einen zweiten?) nicht OpenSource, weswegen eben
> schon laenger ueber Nachfolgeprotokolle diskutiert wird (siehe den von
> mir erwaehnten Link) und weswegen es eben noch nicht so verbreitet ist.

MUDs haben das problem, dass sie nicht TCP connecten können.. es fehlt
ihnen net_connect() - aus diesem grund lassen sie sich von einem
"router" connecten welcher die nachrichten verteilt. das ganze
sternförmig, also reden zwei muds in ägypten via minnesota oder wo auch
immer das ding steht.

dabei bräuchte man nur seinen mud-treiber um eine vernünftige TCP
connect() funktion zu erweitern.

> Darueberhinaus hat man bei IM2 das Problem, dass jedes einzelne MUD z.B.
> eine Channel-Message an ALLE anderen MUDs senden muss. Jedes MUD muss
> also eine moeglichst vollstaendige Liste aller MUDs inkl. aktueller IP

wow.. das ist ja ein zustand wie zu bitnet relay oder noch früher..
vor dns.. vor 1982. sogar irc hat etwas schlaueres routing als das.
aber warum überhaupt einen globalen broadcast-channel-space haben?
ist es nicht MUDdigger, wenn "channels" als räume in MUDs gehostet
sind? man also seine channel subscriptions als betreten in remote
räumen realisiert? die beschränkung, dass man dabei nur in einem
raum zur gleichen zeit sein kann, ist ja nur für das lokale MUD
zutreffend (wegen der environment()-logik von lpmud). man könnte
immernoch als "seelenwanderer" in fremden muds rumspazieren und
dort mitchatten. Dass dann manche Räume strikt chatspezifische
Funktionen haben ist klar. Aber wie konnte es überhaupt geschehen,
dass MUDder ein Chatsystem entwickeln, in dem man keine Befehle
definieren kann und keine Items hineinstellen kann. Wie unmuddig!

> verwalten. Dass das nicht imemr ganz reibungslos funktioniert merkt man
> regelmaessig auf den Kanaelen, wenn einzelne MUDs nicht alles mitkriegen.

Es sollten auch besser nur die MUDs beglückt werden die an einem
Gespräch auch teilnehmen, oder kann man bei intermud sich in Channels
einklinken und mithören ohne dass die sprechenden Teilnehmer davon
erfahren, und es nur auf Wunsch und bei Bedarf? Ich habe das nur mal
sporadisch auf Nightfall benutzt.. bin ja seit der Entwicklung der
Nemesis mudlib weitgehend raus aus dem Mudgeschäft.

Ich gucke gerade mal auf http://ff.mud.de/wiki/bin/view/Mud/InterMud4
und sehe, dass es euer Plan ist ganze MUDs als "jabber user" anzumelden
und die jabber server dann die Kommunikation erledigen zu lassen. Das
bedeutet das quasi ganze MUDs als einzelne Personen gehandhabt werden
und miteinander kommunizieren. Das ist abgefahren und ich frage mich
ob man damit der Individualität der Teilnehmer in den MUDs gerecht wird,
die sind dann nämlich nicht einzeln in jabber existent.

>>Wird es, wenn die Kommunikation mittels xml-Containern ablaufen kann,
>>neue Features geben? Das waere fuer den Normalspieler von Interesse.
>
> Obiges ist IMHO fuer den normalen Spieler durchaus schon eine bedeutende
> Verbesserung. Aber wenn Dir noch weitere Sachen einfallen: XML ist leicht
> erweiterbar, ohne darunterliegende Schichten anpassen zu muessen.

Theoretisch ja, aber die jabber Software ist da nicht so flexibel und
man muss Erweiterungen erst von der jabber Entwicklercommunity
absegnen lassen und warten bis die Clients sie umsetzen. Oder wird
jabber nur als Infrastruktur missbraucht ohne Interkommunikation mit
Jabber-Leuten? Was tut diese Infrastruktur denn, was man nicht mit
eigenen TCP connections oder numerierten UDPs machen kann?
Kann man via Jabber remote Räume betreten?

--
http://symlynX.com/ - network chat technology since 1988
psyc://ly...@ve.symlynX.com - see http://psyc.pages.de/
==> PSYC kann inzwischen IRCen, just /server ve.symlynX.com

Stephan 'Invisible' Weinberger

ungelesen,
08.09.2003, 12:56:4408.09.03
an
* Carlo v. Loesch <ly...@UseNET.pages.de> wrote:

> warum wurden die packets nicht einfach numeriert?

Vermutlich weil das ein ziemlicher Aufwand ist, da ja *alle* MUDs einfach
Pakete ins Netz werfen. Es muesste also zumindest mal fuer jedes MUD ein
eigener Zaehler verwendet werden.

Man wollte halt einfach mal eben zwischen MUDs kommunizieren, ohne
grossen Aufwand zu betreiben.

> MUDs haben das problem, dass sie nicht TCP connecten können..

Was macht dann ERQ_OPEN_TCP des erqd?

> ist es nicht MUDdigger, wenn "channels" als räume in MUDs gehostet
> sind?

Die meisten MUDs werden sowas wohl als "Kanaele" oder "Ebenen" anbieten,
aber die 'Visualisierung' ist ja eigentlich egal.

> zutreffend (wegen der environment()-logik von lpmud). man könnte
> immernoch als "seelenwanderer" in fremden muds rumspazieren und
> dort mitchatten.

Wenn man in fremden MUDs rumspazieren kann braeuchte man eigentlich gar
keine getrennten MUDs mehr, oder? Ausserdem will ich das nicht
implementieren muessen - aber lass dich nicht aufhalten :-)

Was ich mir aber schon oefter ueberlegt habe ist eine "Intermud-Quest",
wo man Teilaufgaben in verschiedenen MUDs loesen muss (sollte natuerlich
auch als Gast moeglich sein). Der "Datenaustausch" wuerde dann aber wohl
eher ueber bestimmte Codewoerter o.dgl. erfolgen, in die man den
Queststatus irgendwie verpackt, damit das anechste MUD weiss was Sache
ist.

> Dass dann manche Räume strikt chatspezifische
> Funktionen haben ist klar. Aber wie konnte es überhaupt geschehen,
> dass MUDder ein Chatsystem entwickeln, in dem man keine Befehle
> definieren kann und keine Items hineinstellen kann. Wie unmuddig!

Wie gesagt: wenn Du das implementieren willst (fuer verschiedene
Mudlibs!) dann haelt dich sicher keiner auf :-)

>> verwalten. Dass das nicht imemr ganz reibungslos funktioniert merkt man
>> regelmaessig auf den Kanaelen, wenn einzelne MUDs nicht alles
>> mitkriegen.
> Es sollten auch besser nur die MUDs beglückt werden die an einem
> Gespräch auch teilnehmen, oder kann man bei intermud sich in Channels
> einklinken und mithören ohne dass die sprechenden Teilnehmer davon
> erfahren, und es nur auf Wunsch und bei Bedarf? Ich habe das nur mal

Aehm, ich vermute langsam, dass wir zwei etwas untershciedliche Meinungen
daruber haben, was ein "channel" ist :-)

Ich rede von sowas wie "D-Chat" u.dgl.

> Ich gucke gerade mal auf http://ff.mud.de/wiki/bin/view/Mud/InterMud4
> und sehe, dass es euer Plan ist ganze MUDs als "jabber user" anzumelden
> und die jabber server dann die Kommunikation erledigen zu lassen. Das
> bedeutet das quasi ganze MUDs als einzelne Personen gehandhabt werden
> und miteinander kommunizieren. Das ist abgefahren und ich frage mich
> ob man damit der Individualität der Teilnehmer in den MUDs gerecht wird,
> die sind dann nämlich nicht einzeln in jabber existent.

Wozu sollte das noetig sein? Jabber ist ja nur als _Protokoll_
interessant, mit dem die einzelnen MUDs ihre Daten austauschen. Aber die
einzelnen User reden nicht im Jabber-Netz sondern weiterhin in den MUDs
und sind dort natuerlich weiterhin als Invisible@Beutelland usw.
erkennbar.

> Theoretisch ja, aber die jabber Software ist da nicht so flexibel und
> man muss Erweiterungen erst von der jabber Entwicklercommunity
> absegnen lassen

Wieso? Die Software sollte unbekannte Tags ("Pakete") einfach
unveraendert weiterreichen, sonst waere es ja sinnlos ueberhaupt XML zu
verwenden.

> und warten bis die Clients sie umsetzen. Oder wird
> jabber nur als Infrastruktur missbraucht ohne Interkommunikation mit
> Jabber-Leuten?

Genau. Wobei "missbrauchen" IMHO das falsche Wort ist, denn es muss ja
nicht zwingend die bestehende Jabber-Infrastruktur genutzt werden. Da das
Teil jOpenSource ist kann man ja auch eigene Server aufziehen.

> Was tut diese Infrastruktur denn, was man nicht mit
> eigenen TCP connections oder numerierten UDPs machen kann?

Man muss die Router nicht neu entwickeln (=das Rad neu erfinden).

> Kann man via Jabber remote Räume betreten?

Will man das?

Carlo v. Loesch

ungelesen,
10.09.2003, 11:25:4710.09.03
an
Stephan 'Invisible' Weinberger wrote:
>>warum wurden die packets nicht einfach numeriert?
>
> Vermutlich weil das ein ziemlicher Aufwand ist, da ja *alle* MUDs einfach
> Pakete ins Netz werfen. Es muesste also zumindest mal fuer jedes MUD ein
> eigener Zaehler verwendet werden.

man muss von jedem sender zu jedem empfänger einen eigenen zähler
führen, das ist technisch kein beinbruch.. und wenn dann eine message
fehlt kann man die betroffenen informieren. die pakete fallen ja
eher selten aus, wenn das netz gerade überlastet ist oder jemand nem
router nen tritt gegeben hat.

> Was macht dann ERQ_OPEN_TCP des erqd?

umständlich genug dass es nicht gerade viele benutzen... aber
sicherlich, man hätte auch damit arbeiten können. warum gibt es
einen "router" der alle muds connectet, statt dass die muds
einander connecten würden um einander die messages zuzuschicken,
a la SMTP?

>>ist es nicht MUDdigger, wenn "channels" als räume in MUDs gehostet
>>sind?
>
> Die meisten MUDs werden sowas wohl als "Kanaele" oder "Ebenen" anbieten,
> aber die 'Visualisierung' ist ja eigentlich egal.

die meine ich ja auch gar nicht, sondern die art der distribution von
intermud-weiten channels wie das d-chat welches Du erwähnst.. alle
knoten im intermud-netz erhalten es, und wenn grad keiner zuhört war's
umsonst.. sowas kann man dann gleich mit einer intermud multicast ip
auf dem MBONE machen, dann ist das routing auch geregelt. jedes mud
sendet ein paket und es verteilt sich an alle empfänger.

>>zutreffend (wegen der environment()-logik von lpmud). man könnte
>>immernoch als "seelenwanderer" in fremden muds rumspazieren und
>>dort mitchatten.
>
> Wenn man in fremden MUDs rumspazieren kann braeuchte man eigentlich gar
> keine getrennten MUDs mehr, oder? Ausserdem will ich das nicht
> implementieren muessen - aber lass dich nicht aufhalten :-)

nur als chat-entität.. das haben wir eigentlich bereits. da in unserem
chatsystem räume nicht anarchisch sind, sondern jeweils auf einem host
residieren, schickt man seinen "join" an diesen host und man ist dort
im raum mit dabei. das ein bisschen hübscher ins mud zu integrieren ist
dann nicht weiter schwer..

> Was ich mir aber schon oefter ueberlegt habe ist eine "Intermud-Quest",

das ist dann aber viiiel schwerer wegen dem authentication trara den
Du schon ansprichst. aber wenn remote objekte ein lokales pendant haben
können ist selbst so etwas machbar... wir liefern schonmal die
gesicherten identitäten..

> Wie gesagt: wenn Du das implementieren willst (fuer verschiedene
> Mudlibs!) dann haelt dich sicher keiner auf :-)

nun das ist der witz an der sach.. wir haben es schon getan..
nicht für verschiedene mudlibs, aber schonmal standalone.

ich rede von unserem in lpc realisierten post-IRC chatsystem,
welches neuerdings publikabel wird und ähnlich wie intermud in
bestehende muds integrierbar ist.. es funktioniert nur radikal
anders. dafür kriegt man IRC-schnittstelle und derlei dazu.

wer noch nie davon gehört hat.. http://psyc.pages.de
die "mudlib" dazu gibt es auf http://muve.pages.de

man braucht nur die master-objekte zu mergen und den wizard-objekten
verbieten auf /net zuzugreifen, und schon laufen die chattechnologie
parallel zum bestehenden mud. dann noch ein wenig klebstoff coden,
und schon kann man nen tell an beliebige psyc-entitäten absetzen...

> Aehm, ich vermute langsam, dass wir zwei etwas untershciedliche Meinungen
> daruber haben, was ein "channel" ist :-)

ne ne ich meine schon die intermud channels.. schade dass nightfall
gerade zerbröselt ist.. war gerade dabei mir das nochmal anzusehen.

im intermud-konzept gibt es kein betreten und verlassen der channels,
sondern lediglich das einschalten eines radiosenders, der sowieso
schon da ist. das ist ein wenig unintimer, aber hat auch was.
jedenfalls benötigt es andauerndes broadcasten an alle angeschlossenen
muds, was nicht gerade skalierungsfreundlich ist..

> Wieso? Die Software sollte unbekannte Tags ("Pakete") einfach
> unveraendert weiterreichen, sonst waere es ja sinnlos ueberhaupt XML zu
> verwenden.

die eigenschaft (zusätzliche header-felder etwa) hat zum glück so
ziemlich jede protokollsyntax.. also die textuellen jedenfalls.
xml bringt nur dann einen mehrwert, wenn man meta-information in
den text einbetten muss, etwa sowas wie

hallo.. ich bin <b>fett</b>!

nachteil von xml ist, dass erschreckend viele implementationen
keinen newline am ende eines tags als paketende akzeptieren,
sondern ein nullbyte erwarten. dadurch sind xml-protokolle so
verbose wie textprotokolle, zugleich aber unfreundlich wie
binärprotokolle. wir haben erst kürzlich den jabber-zugang im
psycmuve gemacht, und das war nicht wirklich amüsant, weil die
jabberclients einem mit x verschiedenen codierungsvarianten
von XML daherkommen.

>>Was tut diese Infrastruktur denn, was man nicht mit
>>eigenen TCP connections oder numerierten UDPs machen kann?
>
> Man muss die Router nicht neu entwickeln (=das Rad neu erfinden).

wie verteilen die jabber daemons die nachrichten denn?
letztlich wieder über tcp roundrobins. und dafür rendert
und parst man extra xml? man bedenke das jabber ein one-to-
one protokoll ist, welches letztlich für gruppen auch nur
unicastet. da ist sogar IRC schlauer. und wenn ich das
richtig sehe ist multicast die intensivste anwendung von
intermud bisher. mit deinem ansatz schiebst du die lösung
des problems an "jemand anders" ab, nur hat der "das rad"
auch noch nicht erfunden.

Stephan 'Invisible' Weinberger

ungelesen,
11.09.2003, 08:22:2711.09.03
an
* Carlo v. Loesch <ly...@UseNET.pages.de> wrote:

> man muss von jedem sender zu jedem empfänger einen eigenen zähler
> führen, das ist technisch kein beinbruch..

Natuerlich nicht, aber warum soll man sowas in UDP implementieren, wenn
TCP es von Haus aus mitbringt?

> die meine ich ja auch gar nicht, sondern die art der distribution von
> intermud-weiten channels wie das d-chat welches Du erwähnst.. alle
> knoten im intermud-netz erhalten es, und wenn grad keiner zuhört war's
> umsonst..

Ja, darum sollen sich MUDs ja beim Router anmelden und die Channels je
nach Bedarf bestellen oder abbestellen koennen.

> > Wie gesagt: wenn Du das implementieren willst (fuer verschiedene
> > Mudlibs!) dann haelt dich sicher keiner auf :-)
> nun das ist der witz an der sach.. wir haben es schon getan..
> nicht für verschiedene mudlibs, aber schonmal standalone.

Ich glaub aber nicht, dass das ausreicht um die Funktionalitaet von a)
dem Spieler, b) seinem Enviroment und c) der Objekte/NPC die mit ihm
interagieren komplett abzubilden.

Messages zu verschicken ist eine Sache, aber komplexere Sachen erfordern
auch ein wesentlich komplexeres "API" in den einzelnen MUDs, das nebenbei
sogar noch zwischen verschiedenen MudLibs uebersetzen muss.

> wer noch nie davon gehört hat.. http://psyc.pages.de
> die "mudlib" dazu gibt es auf http://muve.pages.de

Schau ich mir mal an.

> im intermud-konzept gibt es kein betreten und verlassen der channels,
> sondern lediglich das einschalten eines radiosenders, der sowieso
> schon da ist. das ist ein wenig unintimer, aber hat auch was.
> jedenfalls benötigt es andauerndes broadcasten an alle angeschlossenen
> muds, was nicht gerade skalierungsfreundlich ist..

Darum soll es sich ja aendern :-)

>> Wieso? Die Software sollte unbekannte Tags ("Pakete") einfach
>> unveraendert weiterreichen, sonst waere es ja sinnlos ueberhaupt XML zu
>> verwenden.
>
> die eigenschaft (zusätzliche header-felder etwa) hat zum glück so
> ziemlich jede protokollsyntax.. also die textuellen jedenfalls.
> xml bringt nur dann einen mehrwert, wenn man meta-information in
> den text einbetten muss, etwa sowas wie
> hallo.. ich bin <b>fett</b>!

Jein. Natuerlich kann man wieder ein eigenes Format entwerfen, der
Vorteil von XML ist halt, dass es dafuer schon Parser u.dgl. gibt.

> nachteil von xml ist, dass erschreckend viele implementationen
> keinen newline am ende eines tags als paketende akzeptieren,
> sondern ein nullbyte erwarten.

Das ist allerdings kein Problem von XML, sondern ein
programmiertechnisches. Wenn eine Implementierung unbedingt
nullterminierte Strings erwartet dann ist sie schlicht und einfach falsch.
(ausgenommen natuerlich sie wird explizit z.B. "fuer C" deklariert, dort
sind Strings nun mal nullterminiert).

Carlo v. Loesch

ungelesen,
20.09.2003, 14:03:1420.09.03
an
moin moin.. ich komm mal wieder zum newsen.

> * Carlo v. Loesch <ly...@UseNET.pages.de> wrote:
>>man muss von jedem sender zu jedem empfänger einen eigenen zähler
>>führen, das ist technisch kein beinbruch..

Stephan 'Invisible' Weinberger wrote:
> Natuerlich nicht, aber warum soll man sowas in UDP implementieren, wenn
> TCP es von Haus aus mitbringt?

weil es viel unstressiger ist 1 socket für eine hohe anzahl
gegenstellen zu haben, als einen pool an tcp connections managen
zu müssen. ab gewissen grössen braucht man auch noch os-spezifische
erweiterungen, weil select nicht skaliert.
kommt auf die situation an.. und wie wackelig udp tatsächlich ist.
scheinbar besser als sein ruf, wenn jahrelang damit geschnackt wurde.

> Ja, darum sollen sich MUDs ja beim Router anmelden und die Channels je
> nach Bedarf bestellen oder abbestellen koennen.

okee.. das ist dann zwar immernoch kein routing, aber man hat das
problem des channelmanagements auf ne andere software übertragen.
den usern wird somit verboten eigene privatchannels anzulegen und
die gar ernsthaft zu personalisieren. naja hats ja bisher auch
nicht gegeben. ich weiss ja nicht, aber ich hab den eindruck
privaträume sind genauso wichtig wie öffentliche, oder gar
anonyme "channels".

>> > Wie gesagt: wenn Du das implementieren willst (fuer verschiedene
>> > Mudlibs!) dann haelt dich sicher keiner auf :-)
>>nun das ist der witz an der sach.. wir haben es schon getan..
>>nicht für verschiedene mudlibs, aber schonmal standalone.
>
> Ich glaub aber nicht, dass das ausreicht um die Funktionalitaet von a)
> dem Spieler, b) seinem Enviroment und c) der Objekte/NPC die mit ihm
> interagieren komplett abzubilden.

du redest jetzt von entferntem interagieren.. psyc sieht vor das entfernte
räume befehle definieren können - so quasi nach dem add_action prinzip -
aber deshalb muss man nicht gleich durchdrehen und gegenstände untereinander
tauschen.. give buy environment() .. der kram soll lieber sache des
jeweiligen muds bleiben. ich rede nur von einer möglichkeit leute in
ihrem workroom zu besuchen auf anderen muds, bow smile und say hello
oder wie auch immer das in den neuen deutschmuds heisst. psyc hat sowohl
freie emotes als eine syntax für standardactions (was: "feelings") -
wobei man sich einigen müsste was standard ist.. ne ne zum chatten sind
freie actions eh die antwort - ob sie mud-technisch durch "feeling-befehle"
ausgelöst werden, oder durch :<action> oder /me oder emote is egal.

> Messages zu verschicken ist eine Sache, aber komplexere Sachen erfordern
> auch ein wesentlich komplexeres "API" in den einzelnen MUDs, das nebenbei
> sogar noch zwischen verschiedenen MudLibs uebersetzen muss.

und das is mumpitz.. nicht wirklich sinnvoll.. box der pandora.. stell
dir vor jemand transferiert sich von a nach b geld.. das musste dann wie
blöde kontrollieren.. ne ne, muds sind nicht nur zum spielen da, sie sind
auch eine besonders exquisite form der elektronischen sozialen interaktion,
und *die* kann man sehr wohl vernetzfähig machen und spontaner als das
bisherige im anderen mud einloggen.

>>im intermud-konzept gibt es kein betreten und verlassen der channels,
>>sondern lediglich das einschalten eines radiosenders, der sowieso
>>schon da ist. das ist ein wenig unintimer, aber hat auch was.
>>jedenfalls benötigt es andauerndes broadcasten an alle angeschlossenen
>>muds, was nicht gerade skalierungsfreundlich ist..
>
> Darum soll es sich ja aendern :-)

okay, es wird nicht mehr gebroadcastet sondern nur noch unicastet
an alle teilnehmenden stellen. das is zwar kein routing, aber besser
als gar nix. und was ist mit den unintimen radio-räumen? bei denen
bleibts?

>>xml bringt nur dann einen mehrwert, wenn man meta-information in
>>den text einbetten muss, etwa sowas wie
>> hallo.. ich bin <b>fett</b>!
>
> Jein. Natuerlich kann man wieder ein eigenes Format entwerfen, der
> Vorteil von XML ist halt, dass es dafuer schon Parser u.dgl. gibt.

genau.. das merkt man daran dass es überhaupt kein problem ist libxml
in ldmud einzubinden und du deshalb nen xml parser geschrieben hast
der rekursiv objekte clont und jedes tag mit regular expressions
bearbeitet.. das ist zwar sehr akademisch, aber schnell? naah.
und beherrschst du wirklich alle sonderkonditionen von xml? alle
encodings? überhaupt doctype management? nein, du verwendest ein
subset. also wo is der vorteil von xml?

> Das ist allerdings kein Problem von XML, sondern ein
> programmiertechnisches. Wenn eine Implementierung unbedingt
> nullterminierte Strings erwartet dann ist sie schlicht und einfach
falsch.

nein nein.. die xml-spezifikation sieht bei xml streams vor, dass
pakete mit nullbytes terminiert werden, weil ja das xml dokument als
ganzes nicht terminiert wird. man kann sie auch weglassen, aber dann
muss die gegenseite "raten" wann sie den buffer parsen sollte.
manche gegenseiten sind so nett und tun das.

xml ist für komplexe dokumente gedacht. xmltv zum beispiel ist sinnvoll.
xml als protokoll ist unsinn, das war auch nie das was sich die erfinder
von SGML/XML jeweils gedacht haben. ich war damals auf den web
konferenzen dabei. es ging nur darum das chaos in der HTML-welt zu
stoppen. das hat bis heute nicht geklappt.

das ist so ähnlich wie mit java. java ist für embedded appliances
gebaut, es war fürs web suboptimal (aber verdammt innovativ) und
für server-anwendungen vollkommen bekloppt (aber gut gehypt).
nur dass mit den neuen handies nun java endlich mal den job
kriegt für das es konzipiert wurde. hintergründe zu den aussagen
auf http://java.pages.de.

Stephan 'Invisible' Weinberger

ungelesen,
20.09.2003, 18:19:2120.09.03
an
* Carlo v. Loesch <ly...@UseNET.pages.de> wrote:

> okee.. das ist dann zwar immernoch kein routing, aber man hat das
> problem des channelmanagements auf ne andere software übertragen.
> den usern wird somit verboten eigene privatchannels anzulegen und
> die gar ernsthaft zu personalisieren. naja hats ja bisher auch
> nicht gegeben. ich weiss ja nicht, aber ich hab den eindruck
> privaträume sind genauso wichtig wie öffentliche, oder gar
> anonyme "channels".

Ok, jetzt mal zur Grundsatzfrage: wollen wir hier Intermud oder einen
Chat?

Nebenbei: Wieso sollte das anlegen von neuen Cahnnels prinzipiell
unmoeglich sein, nur weil man sie beim Router "abonnieren" muss?

> du redest jetzt von entferntem interagieren.. psyc sieht vor das
> entfernte räume befehle definieren können - so quasi nach dem add_action
> prinzip

Du redest also von "entferntem reagieren"...

> sache des jeweiligen muds bleiben. ich rede nur von einer möglichkeit
> leute in ihrem workroom zu besuchen auf anderen muds, bow smile und say
> hello oder wie auch immer das in den neuen deutschmuds heisst. psyc hat

Und ich sehe eben genau 0 Notwendigkeit fuer sowas... Wenn ich
Tollerwizard@Tollesmud in seinem Workroom besuchen will, dann will ich
seinen Workroom "wirklich" besuchen. Also werde ich wohl gleich einen
Char in Ttollesmud einloggen, und wenn's nur ein Gast ist.

> > Messages zu verschicken ist eine Sache, aber komplexere Sachen
> > erfordern auch ein wesentlich komplexeres "API" in den einzelnen
> > MUDs, das nebenbei sogar noch zwischen verschiedenen MudLibs
> > uebersetzen muss.
> und das is mumpitz.. nicht wirklich sinnvoll.. box der pandora.. stell
> dir vor jemand transferiert sich von a nach b geld.. das musste dann wie

Hab ich gesagt das ich das _will_? :-) Ganz im Gegenteil; ich halte es
genauso fuer Unsinn, nur war mir eben nicht klar, dass Du das auch tust
:-)

> genau.. das merkt man daran dass es überhaupt kein problem ist libxml
> in ldmud einzubinden und du deshalb nen xml parser geschrieben hast
> der rekursiv objekte clont und jedes tag mit regular expressions
> bearbeitet..

*brrrrr*

Carlo v. Loesch

ungelesen,
21.09.2003, 09:10:5421.09.03
an

Stephan 'Invisible' Weinberger wrote:
> Ok, jetzt mal zur Grundsatzfrage: wollen wir hier Intermud oder einen
> Chat?

ein chat-fähiges intermud.

> Nebenbei: Wieso sollte das anlegen von neuen Cahnnels prinzipiell
> unmoeglich sein, nur weil man sie beim Router "abonnieren" muss?

jabber hat keine vorstellung von conference control, ergo kann ein
privatraum nicht geschützt werden. jeder kann hineinstürmen, jeder
kann ihn zumüllen. du kannst nur intermud-channels anlegen, keine
privatchannels.

> Du redest also von "entferntem reagieren"...

soviel wie in einem kommunikationskontext sinnvoll sein kann ohne
deshalb gleich eine mud-fusion starten zu wollen. wir haben bei
uns beispielsweise gatewayräume in IRC-netze, und nen anderen raum
in dem ein kleiner BASIC interpreter drin ist. jeder im intermud könnte
da hingehen und ne basic expression eintippen oder mit einem ircer
chatten ohne sein mud zu verlassen. und was man sonst so als raum
realisieren kann.

> Und ich sehe eben genau 0 Notwendigkeit fuer sowas... Wenn ich
> Tollerwizard@Tollesmud in seinem Workroom besuchen will, dann will ich
> seinen Workroom "wirklich" besuchen. Also werde ich wohl gleich einen
> Char in Ttollesmud einloggen, und wenn's nur ein Gast ist.

und er wird dich nicht in seinen workroom teleportieren dürfen ohne
ärger mit nem archwiz zu kriegen.. in der regel denk ich mal, bei
uns durften wizzes jedenfalls nicht mit playern interagieren, weil
sonst die traumwaffen übergeben wurden etc.

wär gut hier mal auch andere meinungen als nur Deine und meine zu
hören.. liest noch irgendwer mit? gibt irgendwer einen damn about
intermud?

>>genau.. das merkt man daran dass es überhaupt kein problem ist libxml
>>in ldmud einzubinden und du deshalb nen xml parser geschrieben hast
>>der rekursiv objekte clont und jedes tag mit regular expressions
>>bearbeitet..
>
> *brrrrr*

ja was? verteidige Dich! steh auf! zuck den säbel! :)
is doch nur ein angriff gegen die märe vom einfachen XML,
nicht gegen Deine person!

Stephan 'Invisible' Weinberger

ungelesen,
21.09.2003, 10:53:5221.09.03
an
* Carlo v. Loesch <ly...@UseNET.pages.de> wrote:

>> Ok, jetzt mal zur Grundsatzfrage: wollen wir hier Intermud oder einen
>> Chat?
> ein chat-fähiges intermud.

Mal ganz unter uns: brauchen/wollen "wir" das wirklich?

>> Nebenbei: Wieso sollte das anlegen von neuen Cahnnels prinzipiell
>> unmoeglich sein, nur weil man sie beim Router "abonnieren" muss?
> jabber hat keine vorstellung von conference control, ergo kann ein
> privatraum nicht geschützt werden. jeder kann hineinstürmen, jeder
> kann ihn zumüllen. du kannst nur intermud-channels anlegen, keine
> privatchannels.

Darum heist es ja "Intermud" undnicht "Privatmud"...

>> Und ich sehe eben genau 0 Notwendigkeit fuer sowas... Wenn ich
>> Tollerwizard@Tollesmud in seinem Workroom besuchen will, dann will ich
>> seinen Workroom "wirklich" besuchen. Also werde ich wohl gleich einen
>> Char in Ttollesmud einloggen, und wenn's nur ein Gast ist.
> und er wird dich nicht in seinen workroom teleportieren dürfen ohne
> ärger mit nem archwiz zu kriegen..

Dann erklaer mir, warum ich den Raum via Intermud besuchen _duerfen_
soll? Entweder man _darf_ oder man _darf nicht_ - je nach MUD-interner
Regelung. Wenn man in einem MUD so etwas nicht darf, dann sehe ich keinen
Grund, warum da zwischen "virtuellem Besuch" (Gast-Char) und
"virtuell-virtuellem Besuch" (via Intermud) unterschieden werden sollte,
besonders da BoeserWizard@SuperMud ja auch mit reinem reagieren viel
Bloedsinn anstellen koennte; nachdem ja generell alles ueber Text
ablaeuft ist es ja ziemlich Egal, ob ich eine Ausgabe vom Raum direkt vom
betreffednen Gamedriver beziehe oder auf dem Umweg via Intermud...

> in der regel denk ich mal, bei
> uns durften wizzes jedenfalls nicht mit playern interagieren, weil
> sonst die traumwaffen übergeben wurden etc.

Wenn ihr eure Wizards nicht unter Kontrolle habt hat das aber genau
nichts mit Intermud zu tun :-)

> wär gut hier mal auch andere meinungen als nur Deine und meine zu
> hören.. liest noch irgendwer mit? gibt irgendwer einen damn about
> intermud?

Es lesen hier genug mit...

>> *brrrrr*
> ja was? verteidige Dich! steh auf! zuck den säbel! :)
> is doch nur ein angriff gegen die märe vom einfachen XML,
> nicht gegen Deine person!

Das *brrrr* entfleuchte mir beim Satzteil "deshalb nen xml parser
geschrieben hast der rekursiv objekte clont". Entschuldige, aber wer
sowas verbricht dam ist wirklich nicht mehr zu helfen.
Dass beim parsen rekursiv irgendwelche Datenstrukturen aufgebaut werden
kann man ja vielleicht noch durchgehen lassen, aber Objekte clonen?!?!
Wozu zum Geier?

Natuerlich muss es nicht genau XML sein, von mir aus koennen wir auch
HTML oder gar einen RTF-Ableger oder sonstwas verwenden oder uns ein ganz
neues Format ueberlegen, aber _wozu_? Wozu ein ganzes Format definieren,
wen es die Definition eines Teiles davon (DTD) auch tut?

Ein Grund, warum der letzte Versuch ein vernuenftiges Intermud-Protokoll
aufzustellen gescheitert ist war IMHO auch dass wir uns nicht mal auf
ein Datenformat einigen konnten :-)

Carlo v. Loesch

ungelesen,
21.09.2003, 13:29:0821.09.03
an
Stephan 'Invisible' Weinberger wrote:
> Darum heist es ja "Intermud" undnicht "Privatmud"...

auch "Intermud" hat in diesem sinne kein conference control

> Dann erklaer mir, warum ich den Raum via Intermud besuchen _duerfen_

weil ich programmierbare chatraeume ne geniale sache finde und nicht
gedacht haette ausgerechnet mudder davon überzeugen zu müssen die jeden
tag in programmierbaren räumen agieren.

wie sehr man das mit der eigenen mudlib verquickt oder nicht ist dann
sekundär. die option besteht.

> Wenn ihr eure Wizards nicht unter Kontrolle habt hat das aber genau
> nichts mit Intermud zu tun :-)

ich finde gastzugänge erniedrigend und zudem total ungesichert.
kann sich ja jeder als jeder ausgeben, alles was du siehst als wiz
is ne ip. als player kannste nichmal weiterspielen sondern musst in
irgendein room/church laufen.

> Das *brrrr* entfleuchte mir beim Satzteil "deshalb nen xml parser
> geschrieben hast der rekursiv objekte clont". Entschuldige, aber wer
> sowas verbricht dam ist wirklich nicht mehr zu helfen.

hmm sorry an herrn welzel dessen code wir somit zerreissen. ich
finde die lösung sehr elegant, die er neulich auf der ldmud-liste
gepostet hat, aber eben nicht super schnell. er meinte das gehöre
zu intermud4 via jabber. wie parst ihr denn xml also?

wir haben sowas ja auch, aber eben weil wir für jabber und flash
filme als serverzugang agieren. intern sind wir froh solch eine
verbose syntax mit mühsamer parserei nicht machen zu müssen.
der psyc parser ist hübsch klein. mit den erweiterbaren methoden
und variablen isses zudem abstraktionsfähiger als xml.

> Ein Grund, warum der letzte Versuch ein vernuenftiges Intermud-Protokoll
> aufzustellen gescheitert ist war IMHO auch dass wir uns nicht mal auf
> ein Datenformat einigen konnten :-)

das sollte auch nicht jedes mud selbst implementieren müssen -
die psyc library bietet ne sendmsg() efun und eine msg() lfun,
damit lassen sich die meisten anwendungen von psyc in eigene
objekte einbinden, egal welcher mudlib.

ab dann arbeitet psyc mit ldmud zusammen um multiplexing über tcp
und udp zu bieten, und einen plan wie man echtes routing macht..
also ein paket nach usa, und von dort aus verteilen. die
funktionalitäten von irc, jabber und intermud sind subsets
von psyc. und das ist zufälligerweise auch noch in lpc, weil ich
lpc nach wie vor gut finde.

aber vielleicht rede ich auch zu früh.. noch ist psyc jung und
frisch und macht keine schlagzeilen und die menschen tun sich
unglaublich schwer zu begreifen was es eigentlich ist.

Stephan 'Invisible' Weinberger

ungelesen,
21.09.2003, 16:19:3621.09.03
an
* Carlo v. Loesch <ly...@UseNET.pages.de> wrote:

>> Darum heist es ja "Intermud" undnicht "Privatmud"...
> auch "Intermud" hat in diesem sinne kein conference control

Ja... wozu brauchst Du dann eines? :-)

>> Dann erklaer mir, warum ich den Raum via Intermud besuchen _duerfen_
> weil ich programmierbare chatraeume ne geniale sache finde und nicht
> gedacht haette ausgerechnet mudder davon überzeugen zu müssen die jeden
> tag in programmierbaren räumen agieren.

Doch, aber eben IM Mud. Wenn ich einen Raum im BL progge, dann sollen die
Leute gefaelligst auch einen BL-Char anlegen, damit sie ihn betreten
koennen. Sonst koennte ich genausogut fuer irgendein beliebiges Mud
programmieren...

>> Wenn ihr eure Wizards nicht unter Kontrolle habt hat das aber genau
>> nichts mit Intermud zu tun :-)
> ich finde gastzugänge erniedrigend und zudem total ungesichert.

Erniedrigend? Bitte um Erklaerung...

> kann sich ja jeder als jeder ausgeben, alles was du siehst als wiz
> is ne ip.

Ich denke, man kann auch bei einem Gast-Login feststellen, dass
Gast1@EinMud = DerSpieler@AnderesMud ist. (Z.B. Derspieler etwas
mitteilen, auf das er mit Gast1 antwortet; duerfte recht eindeutig sein).

> als player kannste nichmal weiterspielen sondern musst in
> irgendein room/church laufen.

?

>> Das *brrrr* entfleuchte mir beim Satzteil "deshalb nen xml parser
>> geschrieben hast der rekursiv objekte clont". Entschuldige, aber wer
>> sowas verbricht dam ist wirklich nicht mehr zu helfen.
> hmm sorry an herrn welzel dessen code wir somit zerreissen. ich
> finde die lösung sehr elegant, die er neulich auf der ldmud-liste

Elegant und Effizient sind oft verschiedene Dinge. Die meisten
Rekursionen werden recht "unelegant" wenn man eine (effizientere)
Iteration daraus macht.

> gepostet hat, aber eben nicht super schnell. er meinte das gehöre
> zu intermud4 via jabber. wie parst ihr denn xml also?

Ich parse XML noch gar nicht, weil ich mit IM4 in dieser Form noch nix am
Hut hab. Ich finde nur die Idee interessant XML zu verwenden.

> aber vielleicht rede ich auch zu früh.. noch ist psyc jung und
> frisch und macht keine schlagzeilen und die menschen tun sich
> unglaublich schwer zu begreifen was es eigentlich ist.

Ich muss gestehen: ich auch.

Bastian Hoyer

ungelesen,
05.10.2003, 09:21:0205.10.03
an
Stephan 'Invisible' Weinberger <invi...@xover.mud.at> wrote:


> Was, und ich hab garnix davon mitgekriegt? :-)

Ich werd ja immer von d-code vertrieben wenn ich das boese X?? Wort sag
:)

> Die Verwendung von Jabber/XML klingt auf jeden Fall aeusserst
> interessant, so ist es zumindest mal wesentlich einfacher geeignete
> Router zu finden bzw. aufzusetzen. Ausserdem ist XML natuerlich von
> Haus aus leicht erweiterbar... ja, klingt wirklich gut.

Find ich auch. :)



> Was mir noch ein wenig abgeht ist die Moeglichkeit einer
> Verschluesselung (z.B. fuer "tell"). Auch sollte irgendwie
> ausgeschlossen werden, dass von aussen ein MUD "gefaelscht" werden
> kann... Ich weis, diese Features bietet IM2 auch nicht, aber wenn man
> schon dabei ist ein neues Protokoll zu entwerfen...

Ich glaube das ist bei Jabber/XMPP schon recht gut implementiert.
(Zumindest das man Absender nicht ohne weiteres fälschen kann)

Ich hab mal angefangen ein package fuer den ldmud driver zu basteln das
es sehr einfach macht mit XML Stream Servern zu Kommunizieren. Im
Prinzip wird bei XML Stream eine Verbindung aufgebaut und dann können
von beiden Seiten beliebig XML-Chunks übertragen werden.

Die Package soll mal aus 3 Teilen bestehen, wobei die ersten beiden
soweit schon funktionieren. Zum ersten gibt es 2 efuns die einen XML-
String in ein Mapping umwandeln und umgekehrt. Das sind eigentlich nur
hilfsfunktionen die intern gebraucht werden.

Im 2. Teil gibt es eine Funktion mit der man eine Verbindung zu einem
XML-Stream Server aufbauen kann. Alle XML Chunks die von dem Server
(z,b, ein Jabber Server) kommen werden als Mapping über eine Callback
Funktion in dem Objekt aufgerufen das die Verbindung aufgebaut hat. Die
Sendefunktion akzeptiert auch Mappings und wandelt diese dann in einen
String um und sendet den an den Server.

Der 3. Teil ist im Moment eigentlich nur eine Idee und könnte fuer
Mud2Mud kommunikation genutzt werden. Der Driver könnte auf einem extra
port lauschen und da normal Verbindungen entgegen nehmen. Mit einer
Funktion ähnlich attach_erq_demon() im logon() würde aus dem
interaktiven Objekt praktisch ein XML Stream Server. Aber das ist im
Moment eher nur theorie.

Für das ganze Parsing, XML Erzeugung und auch das connecten zum XML
Stream Server benutz ich die iksemel Library, die Praktisch für sowas
geschaffen ist.

Übrigens sollten sich so nicht nur Clients in LPC programmieren lassen,
sondern auch Jabberserver Komponenten.

Gruss
Bastian

Stephan 'Invisible' Weinberger

ungelesen,
06.10.2003, 13:31:2606.10.03
an
* Bastian Hoyer <new...@dafire.de> wrote:

>> Router zu finden bzw. aufzusetzen. Ausserdem ist XML natuerlich von
>> Haus aus leicht erweiterbar... ja, klingt wirklich gut.
> Find ich auch. :)

Wenngleich man sich vielleicht nicht darauf versteifen sollte. Reizvoll
waere halt die Verwendung bestehender Router-Software, aber wenn das
wirklich so problematisch sein solle, wie Carlo angedeutet hat wird sich
sicher auch ein anderes erweiterbares Protokoll entwerfen lassen :-)

> Ich hab mal angefangen ein package fuer den ldmud driver zu basteln das
> es sehr einfach macht mit XML Stream Servern zu Kommunizieren. Im
> Prinzip wird bei XML Stream eine Verbindung aufgebaut und dann können
> von beiden Seiten beliebig XML-Chunks übertragen werden.

Ah, also wohl doch nicht gar so problematisch :-)

> Der 3. Teil ist im Moment eigentlich nur eine Idee und könnte fuer
> Mud2Mud kommunikation genutzt werden. Der Driver könnte auf einem extra
> port lauschen und da normal Verbindungen entgegen nehmen. Mit einer
> Funktion ähnlich attach_erq_demon() im logon() würde aus dem
> interaktiven Objekt praktisch ein XML Stream Server. Aber das ist im
> Moment eher nur theorie.

Aber eine nette Idee, da man damit nicht von fremden Serevrn abhaengig
waere sondern ein MUD gleichzeitig auch Router spielen koennte (obwohl
hierbei natuerlich die Frage aufkommt, ob es geschickt ist, sowas in LPC
zu implementieren *g*).

Aber fuer so Sachen wie die von mir ertraeumte Intermud-Quest waere sowas
auch sehr brauchbar.

> Übrigens sollten sich so nicht nur Clients in LPC programmieren lassen,
> sondern auch Jabberserver Komponenten.

Ja, aber das ist wie gesagt die Frage, ob das auch nur einigermassen
effizient ist. Fuer kleine Sachen ist es ein nettes Feature, aber einen
Router fuer Intermud-Channels stell' ich mir in LPC potentiell zu langsam
vor...

Tobias Josefowitz

ungelesen,
06.10.2003, 17:29:2606.10.03
an
On Mon, 6 Oct 2003, Stephan 'Invisible' Weinberger wrote:

|> Ja, aber das ist wie gesagt die Frage, ob das auch nur einigermassen
|> effizient ist. Fuer kleine Sachen ist es ein nettes Feature, aber einen
|> Router fuer Intermud-Channels stell' ich mir in LPC potentiell zu langsam
|> vor...

Isses nich. Schau dir Carlos Chatserver mal an, wenn du Zweifel hast. In
dem gibts nicht nur ne angefangene (wie weit der Status jetzt genau ist
weiß ich nicht, aber über den Anfang sollte es sogar schon weit hinaus
sein, ich bin da nur mal vorsichtig) JabberServer-Implementation.
Ausserdem fährt der PSYCmuve von Zeit zu Zeit Chats mit mehreren Tausend
gleichzeitigen Benutzern, was nich grade dafür spricht, dass das Ding
langsam wäre.

Und wenn das geht, kann man auch ein "paar" muds verbinden...

LPC(/LDMud) ist ne sehr alte und somit auch relativ optimierte Sprache
(Kombination).. und ausserdem für solche Zwecke - im Endeffekt nämlich
Netzwerkserver mit Distributionsaufgaben - erstklassig geeignet.

Ausserdem wird LPC ja auchnicht interpretiert sondern ist ne
Bytecodesprache. Und somit doch relativ fix. Von Perl, python und
dergleichen wird ja auch nicht behauptet dass sie langsam wären. Und das
sind auch Bytecode-Sprachen. Selbst Java wird von ner großen Schar von
Entwicklern als schnell (genug) betrachtet (um damit kommerzielle
Serverapps hochzuziehen). Und meistens klappts dann auch.
Und nur weil die Bytecodesprachen im direkten vergleich zu nem C-Server
langsamer sind (in Benchmarks ala: wie oft kann ich in arrays
umherschaufeln etc) heißt das nicht, dass sie im Normalbetrieb nicht mehr
als ausreichend fix sind und garantiert mithalten können.

cu
--
     tobias josefowitz    <to...@goodadvice.pages.de>
--
goodadvice.pages.de: "Machs nur noch schlimmer!"

michael paap

ungelesen,
06.10.2003, 17:35:3906.10.03
an
Tobias Josefowitz wrote:

> Und nur weil die Bytecodesprachen im direkten vergleich zu nem C-Server
> langsamer sind (in Benchmarks ala: wie oft kann ich in arrays
> umherschaufeln etc) heißt das nicht, dass sie im Normalbetrieb nicht mehr
> als ausreichend fix sind und garantiert mithalten können.

Sie können unter bestimmten Bedingungen sogar schneller sein als
statisch übersetzter Code, weil per Just-In-Time-Compiler zur Laufzeit
abhängig von den dann herrschenden Umständen Optimierungen vorgenommen
werden können.

Gruß,
Michael

--
Sollte ausnahmsweise eine Mail-Antwort auf ein Posting vonnöten sein,
bitte folgende Adresse verwenden: newsreply@<Absender-Domain>.

Allen antworten
Dem Autor antworten
Weiterleiten
0 neue Nachrichten