Re: [SRCP] Nachbesserungen des Protokolls, Schwerpunkt Decoder-Ansteuerung (Teil 1)

Hallo,

Edbert van Eimeren <vaneimeren@xxxxxxxxxxx> wrote in
news:fp2i0b$4uv$01$1@xxxxxxxxxxxxxxxxx:

Wir sollten auch nicht übersehen, dass das Benutzer-Interface zum
Zusammenstellen/Auflösen einer MT gegebenenfalls deutlich mehr Aufwand
zu Realisierung benötigt, als zum Fahren einen (bei DCC-Consist) oder
mehrere (in den anderen Fällen) Lok-Befehle an einen SRCP-Server zu
schicken.

Letztlich muss ein Client, das Zusammenstellen/Auflösen einer MT immer
in irgendeiner Weise als Benutzer-Interface anbieten.
Wenn er also sowieso, den aufwendigeren Teil machen muss, warum soll
er dann den einfachen Teil unbedingt an einen Server abtreten (oder
doch selber machen, falls ein konkreter Server das nicht kann).

ACK
Und das ist auch meiner Meinung nach ein Grund dieses nicht im Server zu
machen, da die Konfiguratinsmöglichkeiten das Protokoll doch stark
aufblähen würden.

Der Nachteil der Umsetzung der MT im Client ist, dass die MT dann auch
nur von diesem Client angesprochen werden kann. Andere Clients die nur
die Fähigkeiten implementiert haben Loks zu steuern können so an die MT
keine Befehle senden.
Vielleicht könnten wir auch in die Richtung denken, wie ein Client eine
virtuelle Lok am Server anmelden kann.
Dann könnte man einen beliebig komfortablen Client zur Zusammenstellung
einer MT haben, der von CV19 bis Kennlinienanpassung die
unterschiedlichsten Verfahren, auch mit dem passendne GUI umsetzen kann.
Dieser meldet dann eine neue virtuelle Lok am Server an und alle anderen
Clients können dann mit dieser MT wie mit einer "normalen" Lok
kommunizieren.
Die Befehle werden dann vom Server an den MT-Client weitergeleitet, der
dann je nach seinen und den Fähigkeiten des verwendeten Digitalsystems
entsprechende Befehle an die Lok sendet.

Diese Variante bläht die Kommunikation noch um eine zusätzliche
Clientverbindung auf, auch mit dem daraus resultierenden Zeitverlust.
Allerdings hätte man so ein sehr flexibles System, dass man z.B. auch um
virtuelle Rückmelder ergänzen könnte.

So könnte man Informationen zwischen Clients austauschen, die sich nicht
vom übrigen SRCP Syntax unterscheiden. Ich denke man könnte das auch über
GM lösen, doch wäre man gezwungen, dass alle Clients diese auch
implementiert haben. Ich denke da gerade z.B. an einen Hardwaeclient zur
Loksteuerung, der vielleicht nur GL Befehle implementiert hat und auch
keine MT zusammenstellen will, sie aber trotzdem steuern können sollte.


Grüße
Michael

--

michael DOT o At gmx DOT net
.

Relevant Pages

  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
  • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
    ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
    (Full-Disclosure)
  • Re: What doesnt lend itself to OO?
    ... > rather than client code. ... no way to do that without also touching the object with clock semantics ... will not encapsulate both clock semantics and network semantics. ... The server can do whatever it wants ...
    (comp.object)
  • RE: Fax monitor incoming + outgoing calls?
    ... problem between the client computer and the SBS server. ... Client is using the internal IP address of the SBS server as the ... To the folder redirection GPO issue: ...
    (microsoft.public.windows.server.sbs)