Hallo Leute, Hallo Andreas,
ich stell das wieder zur�ck in die Liste, weil es allgemeinere
Diskussionen dar�ber geben sollte.
> > >Das ist schon ganz sch�n, flickt aber leider noch lange nicht das
> > >Hauptproblem. Sehr viele Provider/Tarife hat getRate() ja per heute
> > >zum Tarifvergleich gar nicht im Speicher, da "rate.c" z.Zt. pro
> > >Provider-Vorwahl immer nur einen Tarif halten kann.
> > >
> > >Oder anders rum: Viele unserer Provider verkaufen gar nicht an Endkunden,
> > >sondern nur an "Reseller", die unter ein und derselben Vorwahl diverse
> > >verschiedene Tarife anbieten (am schlimmsten ist 01098:Star Telecom,
> diese
> > >Vorwahl gibt es gut und gerne in 20 grundverschiedenen Tarifen!)
> >
> >
> > I see
> > Da muss mann/Michi das rate.c total umkrempeln, dass das geht. Dazu habe
> ich
> > auch schon eine Idee:
> > Derzeit ist die zentrale Struktur das Array Provider[1000] mit dem prefix
> > als Index. Das hat den Vorteil, dass jede Funktion direkt auf die Daten
> > zugreifen kann, den Nachteil, dass 1. betraechtliche Loecher im Array sind
> > und 2. obiges Problem nicht abgebildet werden kann.
Vollkommen richtig. ich bin auch todungl�cklich mit dieser Version. Aber
bevor wir das umwerfen (und wir bzw. ich _werden_ das umwerfen!) sollten
wir noch intensiver in uns gehen, in welche Richtung das gehen sollte.
> > Um das zu aendern, muesste das Array indirekt angesprochen werden. Der
> Also m��te die M�glichkeit bestehen, was wei� ich die Tarife *bis* 31. Juli
> und die Tarife *ab* 1. August parallel vorzuhalten.
Richtig.
> Daneben g�be es dann die M�glichkeit nachzurechnen, was dasselbe Gespr�ch
> was wei� ich vor einem halben Jahr gekostet h�tte.
> (F�r ein "isdnrep -a" - Abrechnung aller Daten, die sich angesammelt haben -
> w�re sowas sogar zwingend)
Sehr guter Punkt! Jawohl, das brauchen wir unbedingt!!!!
> Au�erdem gibt es hier das *merkw�rdige* Prinzip, das Kunden bei einem
> Tarifwechsel eines Providers keineswegs *automatisch* zum neuen Tarif
> abgerechnet werden, sondern solange zum alten, bis die Kunden den
> neuen Tarif explizit beantragen. (Ich vermute mal, das da irgend ein
> Gesetz das so verlangt) Auch das m��te isdnlog/isdnrate also eines
> Tages k�nnen ...
Oje. Wir brauchen also sowas wie ein G:-Tag in der rate.conf. Ges��.
> > keine Loecher keine Obergrenze mit 1000 Providern/Varianten.
> > Beim Aufruf aus isdnlog wird die Variante aus isdn.conf verwendet.
> > Der Aufruf aus isdnrate koennte so ausschauen:
> > for (i..
> > Rate->prefix=i;
> > Rate->variant=0; <== NEU
> > getRate retouniert
> > wenn keine Varianten existieren variant=0 und das normale Info
> > sonst variant=nVariant (i.e. maxVariant, die Varianten sollten fortlaufend
> > sein)
> > isdnrate ruft alle varianten auf und bekommt die gewuenchste Info.
> > Die Umsetzung prefix/variant => _prefix (interner index) geht ueber eine
> > kleine Tabelle.
Das habe ich jetzt nicht verstanden. (Was nicht zwingend hei�en mu�, das
es Bl�dsinn ist. Kann auch daran liegen, da� heute Sonntag ist, es
saukalt ist, und ich mittem im HalfLife-Spielen bin)
> > Wenn's der Michi nicht machen will oder er keine Zeit hat, mach's ich.
> Da solltest Du dich mit Michi einigen. Der ist immer ziemlich sauer, wenn
> jemand in "rate.c" Hand anlegt ;-)
> Ich fasse das File schon lange nur noch mit der Bit-Zange an :-)
:-)))
Meine Erziehung zeigt also Wirkung :-)
> Was sagt der Meister von rate.c dazu?
> Wie gefaellt dir mein Patch?
ich habe noch keinen Patch gesehen, obwohl ich sehr neugierig bin.
Der Meister von rate.c (gef�llt mir, der Name) sagt:
zuerst fragt er mal: wie schaut�s denn aus mit stabiler Version erstmal,
und SuSe, und so weiter? Sollen wir das nicht erstmal abschlie�en, damit
wir dann Ruhe haben? ich w�re sehr daf�r, aber das ist Andreas�
Entscheidung.
Dann sagt er: Ja, ihr habt recht, wir m�ssen da was �ndern. Ja, er
w�rde, nachdem wir das durchdiskutiert haben, das gern selbst machen.
dann diskutiert er das Datum: Wie machen wir das? Gibt es nur ein
�g�ltig ab�, oder auch ein �g�ltig bis�? Wie sieht das im rate-xx.dat
aus? ich habe keine rechte Freude mit dem G:-Tag, weil wie reagieren
wir, wenn irgendwo zwischendrinnen im Text pl�tzlich ein G:-Tag
auftaucht? am liebsten w�re mir das Datum direkt beim P:-Tag, dann ist
der ganze Block mit G�ltigkeitsdatum versehen. Ich sehe da jetzt aber
durchaus die Probelmatik, da� bei Tarif�nderungen nicht jedesmal die
gesamte Zonenzuordnung mit A:-tags mehrfach angef�hrt werden sollte.
Andererseits m�ssen wir die M�glichkeit vorsehen, da� ein Provider mit
einer Tarif�nderung auch die Tarifstruktur, und damit die Zonen
ver�ndert. Und �ber allem steht: KISS!!!!
dann diskutiert er die Varianten: ich glaube, es gibt varianten und
varianten. Oder genauer: Es gibt Varianten, die parallel berechnet
werden sollen/k�nnen/m�ssen, und welche, die nicht. Die Telekom Austria
hat z.B. 5 Varianten, die sich nur in der monatlichen Grundgeb�hr und in
dem Preis f�r eine Einheit unterscheiden. Hier mu� ich mich wirklich f�r
eine Variante entscheiden, und insdlog mu� auch nur diese eine Variante
berechnen. Wenn er alle f�nf berechnete, w�rde immer der Tarif mit der
gr��ten Grundgeb�hr und den kleinsten Impulspreisen empfohlen werden,
was ja nicht Sinn der Sache ist. So eine Auswertung (welche der
Tarifabstufungen ist aufgrund meiner Verbindungen des letzten Monats der
sinnvollste) w�re nat�rlich interessant, ist aber nicht Aufgabe vom
isdnlog.
Im Fall, da� unter einer Providerkennzahl mehrere Firmen ihre Leistungen
anbieten, und das momentan als Variante realisiert ist, mu� man
nat�rlich abdecken, in diesem Fall mu� wirklich jede Variante berechnet
werden.
Eine L�sung dieses Dilemmas w�re z.B: Die jetzige Providerkennung (P:XX)
wird von der Providerauswahlnummer abgekoppelt, die
Providertelefonnummer (das was ich vor der Nummer w�hlen mu�) wird ein
Attribug des Datensatzes (also ein eigenes Tag), und die Varianten sind
wirklich nur Tarifvarianten, die nicht parallel berechnet werden m�ssen.
Daraus erg�ben sich mehrere Vorteile:
* unterschiedliche bzw. unterschiedlich lange Providerkennungen w�ren
einfach zu handhaben: Ich mu� eine Telefonnummer nur daraufhin
untersuchen, ob sie am Anfang mit einer der abgespeicherten Kennzahlen
aus der rate.dat �bereinstimmt. (Damit w�re auch das Problem mit den 4-
und f�nfstelligen Providerkennzahlen bzw. der 0 an der dritten Stelle in
�sterreich) gel�st (zur Info: in �sterreich gibt es Provider wie 1001,
was in D ja unm�glich ist, eine Null an der dritten Stelle bedeutet
automatisch eine dreistellige Providernummer)
* Tarifvartianten lie�en sich trotzdem mit einem eigenen Utility
auswerten.
* das P:-Tag mu� nicht mehr numerisch sein, ich kann hier symbolische
Namen vergeben
Ich denke, das reicht erst mal als Diskussionsgrundlage.
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
