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.
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.
Soweit, sogut.
Mein Unverst�ndnis im einzelnen:
* Das Argument, "die Tippslerei zu minimieren" kann ich nicht
nachvollziehen. Es ist doch beim Provider nix weggefallen, oder?
* 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.
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...)
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, 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).
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)
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.
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.
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?
bye, Michi
--
netWorks Vox: +43 316 692396
Michael Reinelt Fax: +43 316 692343
Geisslergasse 4 GSM: +43 676 3079941
A-8045 Graz, Austria e-mail: [EMAIL PROTECTED]
_______________________________________________
Rates4linux-devel mailing list
[EMAIL PROTECTED]
http://lists.SourceForge.net/mailman/listinfo/rates4linux-devel
