Hallo Michi,
----- Original Message -----
From: Michael Reinelt <[EMAIL PROTECTED]>
To: isdnlog <[EMAIL PROTECTED]>; <^@eunet.at>
Sent: Dienstag, 09. November 1999 07:52
Subject: Services
> Hi,
>
> ich habe jetzt nochmal �ber die neue Services-Tabelle am Anfang der
> rate.dat nachgedacht, und irgendwie verstehe ich da was nicht:
>
> Diese Tabelle listet einen Service-Namen und die verschiedenen
> Telefonnummern, unter denen das Service bei diversen Providern
> erreichbar ist, auf.
Ja fast, diese Tabelle definiert *alle* Sondernummern -
providerunabhaengig.
> In dieser Tabelle ist allerdings nicht enthalten, _welcher_ Provider
ein
> Service �berhaupt anbietet, und wenn ja, unter welcher Nummer.
>
> Das heisst, die entsprechende Information ist beim Providereintrag
(dann
> allerdings mit A:-Tag) nochmals vorhanden.
Genau
> Mein Unverst�ndnis im einzelnen:
>
> * Das Argument, "die Tippslerei zu minimieren" kann ich nicht
> nachvollziehen. Es ist doch beim Provider nix weggefallen, oder?
Nein, weggefallen ist nix, aber wenn du jetzt
$ isdnrate 19430
eintippst, kommen nur mehr Provider, die diese Nummer auch anbieten
und nicht zig Provider mit Ortstarif +43 2555 19430.
> * Die Information ist redundant! Eine Sondernummer mu� zwingend in
> dieser Tabelle _und_ beim Provider eingetragen werden, noch dazu
unter
> dem selben S:-Tag, damit wirklich alles klaglos abl�uft.
Nein nicht ganz, es nicht redundant, die Sondernummern am Anfang
definieren Service-Art und Sondernummern, der Providereintrag
definiert den Tarif und damit auch das Vorhandensein dieser Nummern
beim Provider.
> Was w�re, wenn wir das anders machen w�rden (tut mir leid, Leo, ich
wei�
> du hast das schon codiert, aber: selber schuld, wenn wir vorher
nicht
> dar�ber reden...)
Genau - ueberlegen wir einmal probeweise wie's anders einfacher geht.
> Ich sehe zwei auf den ersten Blick recht sch�ne Wege: Beide
verwenden
> keine globale Tabelle am Anfang (also keine redundanten Daten),
rate.c
> klaubt sich die einzelnen Sondernummern bei den Providern zusammen.
>
> 1. Es gibt zus�tzlich zum A:-Tag noch das N:-Tag, das eine
Sondernummer
> kennzeichnet. N:-Eintr�ge funktionieren fast gleich wie A:-Eintr�ge,
nur
> da� die Nummer unter dem entsprechenden Service und beim Provider
als
> Sondernumemr eingetragen wird, damit als bei anderen providern nicht
> w�hlbar gekennzeichnet wird usw. Funktionalit�t wie bisher, weniger
> Tippslerei...
Ack, aber viel groesserer aufwand bei einem getSpecial (aka getArea),
da dann alle Areas, bei allen Providern abgegrast werden muessen.
.. , leichter zu warten (Die globale Sondernummerntabelle ist
> problematisch zu warten, weil sie im Prinzip von jedem Provider (und
> damit von jedem Manager) ge�ndert wird)....
Im Prinzip ja, aber die Sondernummern werden wie Andreas geschrieben
hat von der Telekom-Control ueberwacht, sollten daher wenn einmal
drin, nicht stark geaendert werden muessen.
> Zus�tzlich ist es hier m�glich, eine Nummer bei verschiedenen
Providern
> verschiedenen Services zuzuordnen (auchg wenn das in Deutschland
laut
> Andreas nicht passieren kann - ich f�hle mich wohler, wenns
passieren
> darf)
Dann koennte auch meine beschriebene Erweiterung verwendet werden.
> 2. ohne N:-Tag, aber das S:-Tag funktioniert wie das Z:-Tag: Es
> definiert eine spezielle Art der Zone, die A:-Tags innerhalb dieser
Zone
> sind automatisch alles Sondernummern.
Ist analog zu oben, nur anderer Syntax.
> Beispiel:
> Z:47 Afrika
> A:+81,+82,...
> T:...
> S:Internet
> A:19430,07189*,...
> T:...
> S:Notruf
> A:112,144
> T:0
>
> Achtung: Das S:-Tag definiert hier nicht die Zone n�her, sondern
> er�ffnet eine neue Zone! getLeastCost() vergleicht nicht wie bei
> geographischen Zonen solche mit identischen A:-Tags, sondern bei
diesen
> sogenannten "funktionalen" Zonen solche mit demselben namen.
Aha, dann musst du getLeastCost zwei verschieden Funktionalitaeten
beibringen, bei meiner Loesung war's eher trivial das zu machen.
>
> Mir gef�llt 2. fast besser. Es bietet dieselben Vorteile wie 1.,
aber
> ich finds fast noch eleganter, und eigentlich ist es sogar k�rzer:
>
> bisher:
> Z:50 Internet
> A:19430
> S:Internet
> T:...
>
> Variante 1:
> Z:50 Internet
> N:19430
> S:Internet
> T:...
>
> Variante 2:
> S:Internet
> A:19430
> T:...
>
> wir sparen eine Zeile!
>
> Was sagts ihr dazu?
- Sondernummern scheinen global von der Telekom-Control verwaltet zu
sein
- eine zentrale Verwaltung hat den Vorteil, das das Service nur einmal
definiert wird, bei deinen Varianten besteht immer dieGefahrt, dass
sowas raus kommt:
P:1
.
S:Internet
P:2
S:Cbc
P:3
S:Online
das waeren verschiedene Service, wobei eigentlich ein und dassselbe
gemeint war.
Aber prinzipiell geht deine Variante auch, wenn eine globale
Service-Tabelle aufgebaut wird, dann haben wir eine idente
Funktionalitaet mit etwas weniger Tip-Action.
Aber es muesste eben sichergestellt sein ,dass bei verschiedenen
Provider *exakt* der gleiche Service-Text verwendet wird, und bedenke
dihpfeller bassirn.
leo
_______________________________________________
Rates4linux-devel mailing list
[EMAIL PROTECTED]
http://lists.SourceForge.net/mailman/listinfo/rates4linux-devel
