Hallo Liste
-----Original Message-----
From: Michael Reinelt <[EMAIL PROTECTED]>
To: isdnlog <[EMAIL PROTECTED]>
Date: Sonntag, 25. Juli 1999 15:23
Subject: Re: rate.c
>Hallo Leute, Hallo Andreas,
>
>ich stell das wieder zur�ck in die Liste, weil es allgemeinere
>Diskussionen dar�ber geben sollte.
>> > 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.
>
>:-)))
>
>Meine Erziehung zeigt also Wirkung :-)
Nix Erziehung sonder logische Ueberlegung.
>> Was sagt der Meister von rate.c dazu?
>> Wie gefaellt dir mein Patch?
>ich habe noch keinen Patch gesehen, obwohl ich sehr neugierig bin.
Geht (ging) mit gleiche Post ab.
>Der Meister von rate.c (gef�llt mir, der Name) sagt:
Mag. Rate spricht :-)
>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.
Was ist mit derTrennung in Entwickler und Produktionszweig. Diese
Problematik (Weiterentwicklung v Bugfix) stellt sich doch dauernd.
>
>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.
Tadellos
>dann diskutiert er das Datum: Wie machen wir das? Gibt es nur ein
>�g�ltig ab�, oder auch ein �g�ltig bis�?
Ein "gueltig bis" kann denke ich ja nur von einem "gueltig ab" abgeloest
werden. Wenn nix danach kommt, kann ma nix ausrechnen.
>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.
Na, ich glaube vor dem T:Tags waere es am wichtigsten, aber fuer dir
Umsetzung/Programmierung ist es beim P:einfacher.
>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!!!!
Bussi???
Nun wenn ich an die Tarif + Zonenaenderung unserer PTA am 1.9 denke, und
wenn isdnrep/rate ... einen Bericht ueber ein Jahr bringen sollten, dann
soll alte Variante + neue gleichzeitig vorhanden sein. Ich befuerchte nur
dass das Datenmaessig in die zigMBs ausufern koennte.
>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.
Denk nicht nur an isdnlog. isdnrate bringt einen Preisvergleich was wohin
kostet. Die naechste Stufe ist (und darum auch standardisierte Gebuehren)
ist, was das inkl alller Grundkosten pro Monat/Jahr bei einem bestimmten
Gespraechmix kostet.
>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.
isdnrate
Wobei die 4 Buchstaben i,s,d,n da drin eigentlich schon zu viel sind.
>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.
Der Mann ist genial. Aber bitte keine Unterscheidung von Varianten. Alle
Daten muessen zugaenglich sein. Ich moechte auch PTA Standardtarif mit
Minumum+Geschaeftstarif 1,2,3 vergleichen koennen, und zwar mit
Grundgebuehr.
>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)
Also das Teil von normalizeNumber namens split_vbn wuerdest du uebernehmen.
>* 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
Also interner Index ist Provider+Variante+Datum-ab oder?
leo
_______________________________________________
Rates4linux-devel mailing list
[EMAIL PROTECTED]
http://lists.SourceForge.net/mailman/listinfo/rates4linux-devel
