Alexander Skwar wrote:
> Dadurch lie�e sich eine einfachere Wartung erreichen, da man dann nicht
> mehr bei einer Preis�nderung alle Provider bearbeiten m��te, sondern nur
> noch einen. Auch w�rde dies die Gr��e der rate-de.dat reduzieren (hmm,
> dann fallen wir ja wieder hinter �sterreich zur�ck. Doch nicht so gut
> der Gedanke :-]).
Doch, die Idee find ich gut :-)
> Was wir br�uchten, w�re also eine Art "Default-Provider". Zuerst wird in
> der rate-de.dat nachgeschaut, ob es Treffer gibt. Wenn nicht, dann wird
> der Default-Provider befragt.
>
> Super w�re es nun, wenn man zwischen den Default-Provider, und der
> rate-de.dat noch eine Stufe dazwischen bauen k�nnte, so eine Art
> "Semi-Default-Provider". Dieser Semi-Default sollte dann von der
> rate-de.dat einstellbar sein.
>
> Wenn man sich z.B. 01027 genau anschaut, so wird man festellen, das der
> Unterschied zwischen 01027 und 01027,1 nur der Internet Tarif ist. Hier
> w�re es sch�n, wenn ich sagen k�nnte, das sich halt nur der Internet
> Tarif unterscheidet, und alle anderen Zonen von 01027 �bernommen werden
> sollen.
>
> Innerhalb eines Providers k�nnte man dies vielleicht erreichen, indem man
> das Z: Tag durch ein anderes Tag ersetzt (D: ?). Liest isdnlog nun ein
> D: ein, so merkt er sich, das diese Zone ein Default f�r diesen Provider
> sei.
>
> Taucht nun ein Gespr�ch zu diesem Provider auf, so sucht er erstmal ganz
> normal wie bisher. Wird nichts gefunden, so schaut er in der D: Liste
> f�r diesen Provider nach. Bleibt die Suche auch hier negativ, so wird
> als letztes der Default Provider befragt.
Vor kurzem ist hier noch der Wunsch nach einer einstellbaren
Default-Taktung aufgetaucht. Ich als Autor des Parsers sage jetzt
folgendes:
Das Format der rate-xx.dat ist komplex genug. Ich habe nicht vor bzw.
halte es f�r keine gute Idee, daran noch herumzudoktern. Der Parser
funktioniert halbwegs verl��lich, und die Tarifberechnung ebenso.
(Andreas und ich k�nnen Geschichten �ber die Startschwierigkeiten
erz�hlen).
Anmerkung zur Taktung: Das Format (60) ist eigentlich nicht als
Erleichterung gedacht, sondern zur Verhinderung von Rundungsdifferenzen.
Wir haben ein einigerma�en allgemeines Format gefunden, mit dem sich bis
jetzt alle Spezialf�lle recht sauber abdecken lassen. Ich bin daf�r,
dieses Format beizubehalten. (Daf�r gibts an anderer Stelle, mit den
A:-Tags und dem neuen S:-Tag und der country.c und der zone.c eh mehr
als genug Ver�nderung).
Andererseits kann ich eure Argumente verstehen, die rate.dat leichter
wartbar zu machen. Wir in �sterreich stehen vor �hnlichen Problemen,
z.B. bietet die Telekom Austria ihr gesamtes Tarifmodell in 4
verschiedenen Varianten an, die sich nur im Verh�ltnis von monatlicher
Grundgeb�hr zum Preis einer Einheit unterscheiden (das ist auch der
Grund, warum die rate-at.dat so gro� ist). Alle anderen Parametert (die
Dauer einer Einheit in den verschiedenen Zonen) ist in allen Varianten
gleich. Eine �nderung w�re also immer an vier Stellen einzutragen.
Die L�sung des Problems ist grunds�tzlich einfach: Ich warte nicht die
rate-at.dat dfirekt, sondern nur ein Programm, das die rate-at.dat
erzeugt. Eine Art Preprozessor also.
Ich denke, da� sich so ein Preprozessor (ob in C, Perl, Shell-skript,
Tcl oder Visual Basic :-) auch f�r die deutschen Provider verwenden l��t
(rate-at.c verwendet f�r jeden Provider eine eigene C-Funktion). Dabei
ist nicht gesagt, da� man einen Preprozessor f�r alle Provider verwenden
mu�. Manche Provider sind vielleicht so einfach, da� sich der Aufwand
gar nicht lohnt. Ich halte es auch nicht f�r sinnvoll, sich jetzt noch
ein Zwischenformat zu �berlegen, das so m�chtig ist, da� es aus einer
Meta-Datei alle Provider erzeugen kann.
KISS - keep it small and simple
bye, Michi
--
netWorks Vox: +43 316 698260
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
