Hallo Rate-Hunter sowie isdnlog-Programmierer!
Karsten Keil fragte mich gestern nach einer stabilen Version des
isdnlog, da er *jetzt* damit beginnt, f�r die SuSE 6.2 den ISDN-Kram
fertig zu machen. (die SuSE 6.2 kommt im Herbst raus, die Beta recht
bald)
Daher rufe ich hiermit ein "Feature freeze" aus, d.h. ab
sofort flie�en nur noch Bug-Fixes und �hnliches in den isdnlog ein,
neue Features m�ssen leider warten (wobei ich gerne bereit bin, neue
Features bei mir zu Hause lokal zu sammeln).
Eure evtl. Frage: Was geht uns SuSE an? M�chte ich auch gleich beantworten:
1. Ich arbeite *nicht* f�r SuSE
2. Ich habe es auch in Zukunft nicht vor (obwohl man mich gefragt hat ...)
3. Ich bekomme keinerlei Geld oder sonstige Unterst�tzung von SuSE
4. Ich habe genaugenommen gar nix mit SuSE zu tun
5. Die einzige Schnittmenge zwischen SuSE und mir besteht in einer
privaten Freundschaft zu Karsten Keil
6. Die SuSE ist die mit weitem Abstand am h�ufigsten in Deutschland
eingesetzte Distribution. Daher werden viele Leute, die heute noch
brav und anst�ndig mit den isdn4k-utils-beta2 arbeiten, durch Kauf
der SuSE 6.2 *unseren*aktuellen*CVS*Stand* auf ihre Kisten bekommen.
Und genau hier liegt mein Problem: Sobald die SuSE 6.2 drau�en ist,
explodiert mein Mail-Folder mit hunderten von Mails in der Form:
"Ich habe mir heute die SuSE 6.2 gekauft, und jetzt geht mein
isdnlog nicht mehr. Was ist zu tun?"
Ich *hasse* diese Mails, es ist bei jeder neuen SuSE-Version dasselbe
gewesen, und ich habe keine Lust mehr darauf!
Obwohl ich jedem fragenden immer wieder gerne helfe, bin ich zeitlich
einfach nicht mehr dazu in der Lage, mich um jedes Wehwehchen da
drau�en zu k�mmern!
Daher schlage ich folgende Road-Map vor, und bitte euch alle, mir dabei
zu helfen:
1. Ich habe gestern isdnlog-3.40 eingecheckt. Diese Version kompiliert
absolut fehlerfrei und warnungslos durch.
Ein "make install" installiert alle relevanten Files korrekt.
Diese Version hat Karsten nun auf dem Tisch, und baut daraus die
SuSE 6.2
2. Es gibt noch eine ganze Reihe von Dingen, die ich gerne noch auf der
SuSE 6.2 draufh�tte, und im Laufe der n�chsten Tage Karsten auch noch
unterschieben kann:
- das "configure" im Verzeichnis "isdnlog/tools/zone" wird nicht
aufgerufen. Vielmehr habe ich ein fertiges "config.h" in's CVS
eingecheckt. Das geht solange gut, wie die Zielmaschine einen
Intel-Processor und die libgdbm besitzt.
W�re sch�n, wenn das noch sauber gefixt wird.
- Das "make install" installiert z.Zt. alle Daten-Dateien mit einem
"-de" oder "-at" ... im Namen. Das pa�t in Deutschland auch wunderbar,
aber in �sterreich gibt's ein kleines Problem:
Es gibt z.Zt. keine "country-at.dat", daher macht der "make install"
dort eine Bauchlandung.
- Da� das Modul "zone.c" mit einigen gcc Versionen zu Bl�dsinn
kompiliert wird, ist unsch�n, und d�rfte noch bei anderen Leuten
zu Problemen f�hren.
- Beim Start von isdnlog/isdnrep/isdnconf/isdnrate erschienen bis
vorgestern eine Unmenge an (begr�nderer!)
Warnings -> Unknown country ...
Die Warnings habe ich in isdnlog-3.40 unterdr�ckt (in Zeile 386
des Moduls "rate.c" mu� aus "PRT_ERR" ein "PRT_NORMAL" gemacht
werden, damit die Warnings wieder auftauchen)
Alle Warnings besagen, da� in der "country-de.dat" noch diverse
Alias-Eintr�ge f�r L�nderbezeichnungen fehlen.
W�re sch�n, wenn die jemand nachtr�gt, denn das ist der Grund,
warum alle isdn* Tools momentan so �tzend langsam starten:
Michael's "rate.c" sucht nach �hnlichen L�nderbezeichnungen,
und das dauert *ewig*.
F�r eine evtl. WEB-Anfrage dauert das viel zu lange, und kann
nur durch Korrekturen in der "country-de.dat" verbessert werden!
- isdnlog/isdnrate ... wei� z.Zt. �berhaupt nicht's mehr von
Sonderrufnummern. Bei "Auskunft Inland" kann ich z.Zt. damit
leben, bei "Internet by call" Nummern *nicht*, da da� ja
der prim�re Einsatzzweck des isdnlog ist!
Ich habe eben mal angefangen, in der "rate-de.dat" bei allen
"Internet by call" Angeboten das Service-Tag zu f�llen:
Z:xx
A:019xxxx
S:Internet by call
T:....
Dies mu� "rate.c" nat�rlich noch auswerten!
1. Mu� isdnlog die (wieder) finden, d.h. wenn jemand T-Online
oder Arcor-Online oder sonstwas anw�hlt, mu� isdnlog den
richtigen Preis und die korrekte Taktl�nge (CHARGEINT!!)
wissen.
2. "isdnrate" (das neue Tool zum Befragen der "rate-xx.dat")
darf nur "Internet-by-call" Angebote miteinander vergleichen.
- Einige der neuen Eintr�ge in die "isdn.conf" werden vom "make install"
noch nicht durchgef�hrt. Z.Zt. geh�ren folgende (neue) Eintr�ge
dort rein:
[GLOBAL]
COUNTRYPREFIX = +
AREAPREFIX = 0
COUNTRYCODE = 49
AREACODE = 6171
AREADIFF = /usr/lib/isdn/vorwahl.dat
CODELIB = AREACODE
AREALIB = /usr/lib/isdn/areacodes
[ISDNLOG]
COUNTRYFILE = /usr/lib/isdn/country-de.dat
HOLIDAYS = /usr/lib/isdn/holiday-de.dat
RATEFILE = /usr/lib/isdn/rate-de.dat
RATECONF = /etc/isdn/rate.conf
ZONEFILE = /usr/lib/isdn/zone-de-%s.gdbm
Ich wei� nicht mehr, welche Eintr�ge bereits automatisch gemacht
werden, und welche "per Hand" nachgetragen werden m�ssen.
- Einige Eintr�ge in der "rate-de.dat" sind ganz offensichtlich
falsch. Ich kann leider (bei der Gr��e der Datei verst�ndlich!)
immer nur Stichproben machen, und wenn mir was auff�llt, korrigiere
ich das auch (fast) immer gleich.
Aktuelles Beispiel: Ich glaube einfach nicht, das 153 Sekunden USA
bei GTS-WESTCom DM 5,661 kosten, wenn sogar die DTAG daf�r nur
DM 1.920 haben will!
Evtl. w�re ein Programm sinnvoll, das einen Pr�flauf machen kann:
- f�r jede Vorwahl den DTAG-Preis berechnen
- f�r jeden Provider dessen Preis daf�r berechnen
- wenn der Provider > 200% �ber dem DTAG-Preis liegt, Alarm schlagen
oder sowas in der Art ...
Ich habe bewu�t bei keinem der obigen Punkte "hier, ich" geschrieben,
da ich mich bei *jedem* der Punkte dar�ber freuen w�rde, wenn es
jemand anderes macht ... meine freie Zeit ist momentan ziemlich
knapp bemessen, und im August mu� ich mich sogar mal ganz abmelden.
3. Es gibt eine ganze Reihe von Dingen, die ich f�r den n�chsten isdnlog
(Version 4.00) gerne h�tte, und die neben der "stable version"
entstehen sollten:
- aktives LCR mit isdnlog. Dieses Projekt macht gute Fortschritte, wird
aber definitiv nicht auf der SuSE 6.2 zu finden sein - dazu ist es
noch zu frisch
- Beauskunftungstool "isdnrate", das auch sp�ter das Backend f�r
Alexanders WEB-Abfrage-Seite werden soll.
Zum Gl�ck ist "isdnrate" ein vollkommen eigenst�ndiges Tool geworden,
das bislang nicht mal im "README" erw�hnt wird.
Daher ist es durchaus m�glich, daran kontinuierlich weiterzuarbeiten,
ohne die Auslieferung der SuSE 6.2 zu behindern.
Ich pers�nlich werde das auch tun - soweit meine Zeit mir das
gestattet.
Alexander: Ich habe Deine "Wunschliste" dazu durchaus gesehen!
Meine Anwort dazu in zwei S�tzen:
1. Sauberes Design, gef�llt mir gut
2. Wer soll das alles programmieren?
Ich versuche mich bei meinen Erweiterungen an "isdnrate" auf jeden
Fall an Deine Wunschliste zu halten, aber alles kann ich Dir f�r
die n�chsten Tage sicherlich nicht versprechen!
- Massive Erweiterung der "rate-xx.dat" Struktur (ja, ja, Michael ;-)
Das heutige Schema mit "P:xx" und dem selektieren von Untereintr�gen
via "rate.conf" ist leider mittlerweile fast unbrauchbar geworden.
Der Markt ist daf�r einfach viel zu schnelllebig geworden.
Sp�ter einmal *mu�* jeder Tarif im Speicher sein, nicht nur jeweils
einer pro "P:"
Tolles Beispiel dazu:
Es gibt eine Telefongesellschaft
P:18 Debitel
Die bieten aber auch einen Tarif unter der Provider-Vorwahl
P:15
an. P:15 ist aber eigentlich die Firma RSL COM
Ein anderes Beispiel ist der Provider "P:98 Star Telekom", der
mit Sicherheit 10..20 verschiedene Reseller mit jeweils wiederum
1..5 verschiedenen Tarifmodellen im Angebot hat. F�r einen
Tarifvergleich *mu�* "isdnrate nat�rlich *jeden* Tarif im
Speicher haben!
F�r isdnlog ist das nicht schlimm -- jeder Mensch kann nur bei
"P:15 RSL COM" oder bei "P:15 debitel" angemeldet sein, aber
f�r einen Preisvergleich �ber alle ist das Verfahren unbrauchbar.
Daneben kommen wirklich t�glich neue Tarife raus, daher ist es
unabdingbar, das wir das Tag "G:" (g�ltig ab) als weiteres
Sortierkriterium bekommen, *alle* Tarife im Speicher halten, und
wenn das Kalendarische Datum wechselt, evtl. umschalten (also
bitte nicht via "cron", das ist popelig!)
Imho m��te die "rate-xx.dat" bald so aufgebaut sein:
P:* <- meint nur noch: Hier f�ngt ein neues
Tarifmodell an
N:15 <- diese Vorwahl m��te vorgew�hlt werden
C:debitel via RSL COM <- Name von dem Zeux
G:01-Jul-1999 <- Tarif g�ltig ab
oder so �hnlich ...
So, jetzt schlie�e ich mal - diese Mail ist sowieso schon viel zu lang
geworden.
Ihr seht jetzt aber auf jeden Fall den aktuellen Status rund um isdnlog.
Abschlie�end: Auch wenn ich nicht jede Mail in der "Rate" Liste beantworte,
k�nnt Ihr sicher sein, da� ich alles lese, und im Einzelfall auch darauf
reagiere. Leider wird meine freie Zeit aber momentan immer knapper, und
daher mu� ich mit dieser kostbaren Resource sehr vorsichtig umgehen.
Ich hoffe da einfach mal auf euer Verst�ndnis!
Ciao,
Andreas
--
Andreas Kool ([EMAIL PROTECTED] * http://www.pweb.de/kool.f)
PGP: 3FBF2411 Fingerprint: B5 35 34 74 25 60 2A 7A 89 06 92 C4 08 BA A5 BD
(To get my PGP key, send me a mail with subject "send pgp key")
Transmission of this message via the Microsoft Network is prohibited
_______________________________________________
Rates4linux-devel mailing list
[EMAIL PROTECTED]
http://lists.SourceForge.net/mailman/listinfo/rates4linux-devel
