> Andererseits: Wieviel Zeilen sind es,
>
> a) das aktuelle Datum der rate-xx.dat zu ermitteln
> b) den Zeitpunkt der n�chsten Tarif�nderung irgendwo zu vermerken und
> c) in regelm��igen Abst�nden nachzusehen, ob das Datum aus a) nicht mehr
> stimmt
> oder das Datum aus b) erreicht ist (und dann die Tabellen neu
> aufzubauen und
> ein neues Datum zu merken)?
>
> Mehr als 20?
Nat�rlich! Wir m�ssten den neuen Code ja auch dokumentieren!
Vorerst wird das G:-Tag �berhaupt nicht ausgewertet, das m�sste ich erst
mal implementieren. Dann mu� man darauf R�cksicht nehmen, da� die
Datenbank sequentiell gelesen wird, wenn die Daten des G:-Tags nicht
nach aufsteigendem Datum sortiert sind, kann�s da zu Problemen mit dem
Einlesen kommen. Sich dabei die n�xte Tarif�nderung zu merken, und sich
selbst einen HANGUP zu schicken, sollte dann kein unl�sbares Problem
mehr sien.
Alles ist technisch machbar, aber mit etwas Aufwand. Wenn ihr die
Diskussion in der isdn4linux-Liste verfolgt habt, dann sollte euch
eigentlich auch eines klar sein: Wir m�ssen ab jetzt in regelm��igen
Abst�nden eine stabile Version rausbringen. Daraus folgft, wir d�rfen
nicht blind neue Features einbauen, die sich erst stabilisieren m�ssen,
wenn diese Stabilisierungsphase eingetreten ist, sind inzwischen schon 5
neue Features dazugekommen, und wir haben wieder jahrelang keine Version
f�r die Allgemeinheit.
Mit anderen Worten: eine gute Idee, bitte f�r die Version 4.1 vormerken
(wenn wir davon ausgehen, da� 4.0 eine stabile Version werden soll).
Das w�re gleich das Stichwort: sollen wir eine �hnliche
Versionskonverntion wie der Linux-Kernel einf�hren? gerade Versionen =
stabil, ungerade = Entwickler?
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
