[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DDL-ML] Welcome String nochmals



Hallo zusammen,

>
> > Dabei prüfe ich ab auf Daemon Art, version und SRCP Version.
> >Ich möchte daher verbindlich eingetragen haben als
> >Formatierung des Welcome Strings:
> > <servername><blank><versionsnummer>;SRCP<blank><versionsnummer>
>
> ähh, täusche ich mich, oder sieht der nicht jetzt sowieso schon so aus. Am
> Ende des Kapitels 1.2 der SRCP-Doku steht er doch genau so beschrieben. Ich
> versteh die Anfrange nicht.

Im SRCP steht *sollte*, und nicht *muß*. Das heißt auf gut deutsch: es ist
empfehlenswert, das diese Informationen drinstehen, eine Verpflichtung ist das
jedoch nicht. Wir diskutieren jetzt, daraus eine Verpflichtung zu machen und
wollen festlegen, wie die aussehen soll.

Stefans Vorschlag hierzu, der auf seinem Clientprogramm heraus entstanden sein
dürfte, besagt eine zweiteilige Information: Servername, dessen Versionsnnummer
(3-stellig, wie ich einer Mail von Stefan meine entnehmen zu können), gefolgt
von einem Semikolon und dann dem String SRCP und dessen implementierte Version
(ebenfalls 3 stellig, das ist nunmal so).

Was mir an diesem Vorschlag nicht gefällt ist, a) das der Server eine
dreistellige Versionsnummer pflegen soll (bzw. überhaupt eine numerische
Versionsnummer, mein Server hat da "Januar 2001" drinstehen, z.B) und das es nur
diese beiden Felder geben darf (noch dazu in dieser Reihenfolge). Ersteres ist
ganz klar eine Macke von mir, letzteres halte ich für wichtig genug, das
ausdiskutieren zu wollen. Grundsätzlich halte ich die Festlegung des
Informationsgehaltes für gut, aber das ist wohl völlig untergegangen. mea culpa?

Ich stehe auch nicht gegen Veränderungen, nur "weil gewisse Leute auf ihrem
Stand beharren wollen", ich denke aber, daß die Aufgabe das Werkzeug bestimmt
und nicht umgekehrt (das soll jetzt keine Unterstellung gegenüber irgendjemand
sein, also bitte nicht mißverstehen). Und das SRCP sehe ich als ein (das)
Basisprotokoll, das einige Dinge absichtlich nicht erledigt, an. Dazu gehören
alle möglichen Monitoringmaßnahmen. Diese lassen sich aufbauend auf dem
SRCP definieren. eine Realisierung im Server selbst würde eine unnötige
Mehrfachentwicklung nach sich ziehen, wenn z.B. jeder Serverentwickler das
Überwachen der Weichen aufs neue implementieren muß (mit immer gleichen
Algorithmen, anderes Beispiel wäre die Zugverfolgung: Welcher Zug ist wo, auch
das braucht eigentlich jeder, aber auch das gehört nicht in den SRCP Server).
Das kann eine übergeordnete Instanz viel besser (die vielgerühmte Middleware).

Was das SRCP aber macht, ist, von der Modellbahnhardware und deren doch manchmal
kryptischen Ansätzen wegzukommen, alle denkbaren Informationen einzusammenln und
via Netzwerk an alle interessierten zu verteilen. Und von dort Befehle
anzunehmen, damit auf der Anlage das passiert, was passieren soll.

Damit ein tolles Programm sofort und ohne weitere Anpassungen sowohl für die
DDL'ler, die IB'ler, die Märklin-Puristen, die N-Bahner, die LGB-Fraktion etc
(wen hab ich vergessen?) funktioniert. Das bislang nur Linuxer in den Genuß
kommen können, scheint sich ja zu ändern :=)).  Auch ohne das der/die Entwickler
sich um alle Einzelheiten der Hardware kümemrn müssen (wie es viele der jetzigen
Programme ja machen).

Ich hoffe, das mein Standpunkt a) klarer geworden ist und b) auch akzeptabel
ist. Das der Ton die Musik macht, nun ich gelobe Besserung.


Viele Grüße
Matthias

--
GPGP
1024D/77E30063 1999-10-24 Matthias Trute mailto:mtrute@topmail.de
http://members.tripod.de/mtrute/