Hi Leute,
> >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.
Andreas?
> >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.
Lat�rnich. Ich Todel. Also nur ein "G�ltig ab"
> >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???
Keep It Small & Simple (oder: Keep it stupid simple)
> Nun wenn ich an die Tarif + Zonenaenderung unserer PTA am 1.9 denke, und
Info f�r unsere deutschen Freunde: die PTA krempelt da alles um: aus 4
Zeitfenstern werden 2, aus 3 Inlandszonen werden 2, usw.
> 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.
Eben. Und eben.
Hat wer eine vern�nftige Idee (die ich nicht gleich wieder zerlege :-)
Eine (bl�de) Idee w�re: Ein Provider mit einer neuen Tarifstruktur ist
ein neuer Provider. Eigentlich gar nicht so bl�de...
> >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.
Einverstanden. Wie/wo kodieren wir Grundgeb�hren? Minimalums�tze sollten
da auch noch rein. Eigentlich auch Rabattstufen, aber da wird�s dann
l�stig....
> >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.
Das ist allerdings auch ein guter punkt....
> >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.
hast auch wieder recht. Also sind die 5 Varianten der PTA eigentlich 5
Provider. In der rate.conf mu� der User sagen, bei welchem der Provider
er gebucht ist (also welchen Tarif er gekauft hat).
Frage an Radio Eriwan: Kann man in Deutschland bei mehreren providern
gebucht haben, die unter derselben Providerkennung laufen? Eigntlich
rein technisch nicht. Wie regeln die das?
insdlog (bzw. initRate()) w�rde den Fall, da� man per rate.conf bei zwei
Providern mit derselben Kennzahl gebucht ist, eine Warnung ausgeben.
> >* 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.
ja, nat�rlich! Das macht Sinn!!
Frage: Was bedeutet �vbn�? oder gibts da einen standardisierten Namen
f�r die Providerkennzahl? Wien nennen wir das Tag?
> Also interner Index ist Provider+Variante+Datum-ab oder?
Es gibt keine Varianten mehr?
Vielleicht machen wir das Datum-ab doch bei den T:-Tags dazu? So oft
werden die wohl nicht das Verzonungsschema �ndern. Und wenn, dann wird�s
ein neuer Provider.
Das w�re ja auch insofern sinnvoll, weil Tarife u.U. nur im Inland
ge�ndert werden, und die Auslandstarife gleich bleiben. (ist das so, in
Deutschland?). Die A:-Tags werden sich auch nicht dauernd �ndern (id das
so, in Deutschland?), und wenn, dann neuer Provider.
Formatvorschl�ge:
T:1.7.99:1-5/8-18=0.2(60)/1
T[1.7.99]:1-5...
T:[1.7.99]1-5/...
T/1.7.99:1-5...
mir gef�llt bis jetzt die letzte am besten, ist auch einfach in den
Parser zu integrieren.
ein standardisiertes Datumsformat m�ssen wir uns noch �berlegen
(international und so...)
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
