On Mon, Aug 23, 1999 at 06:38:16AM +0200, Michael Reinelt wrote:
> Hi Leute,
>
> > Also Sondernummern (Handy, Auskunft) sind normale Nummern die in einer
> > anderen Zone liegen. Sie haben einen Eintrag in CC/code (Bezeichnung,
> > Abtrennung von normaler Nummer) und einen Eintrag in rate-CC.dat (Tarife).
> > That's ist, funktioniert jetzt auch schon ohne Klimmzuege.
>
> Ja, das ist zwar richtig, aber wir haben dann eine Information an zwei
> Stellen, die u.U. widerspr�chlich sein k�nnen. Anfangs wollte ich eher
> dem Leo zustimmen, weils eh schon so funktioniert, wie Leo sagt.
> Mittlerweile schlage ich mich eher auf die Seite vom Andreas. Oder auch
> nicht. Ich bin hier unschl�ssig.
Ok, dann mu� ich hier mal ein "Machtwort" sprechen:
Da in der Verzonungstabelle jede "Vorwahl" nur einmal drinsteht, in der
"rate-xx.dat" jedoch beliebig oft, ist die Fehlerquote geringer, wenn
wir alles erst mal in die Verzonungstabelle reinschreiben. Korrekt?
Daher sehe ich folgenden Flow:
1. isdnlog "sieht" die Nummer "007/4711"
2. isdnlog befragt die Verzonungstabelle: Was'n das?
3. Verzonungstabelle antwortet: Das ist die Vorwahl von "James Bond",
und ist 3 Ziffern lang
4. isdnlog zeigt das textuell an
5. isdnlog fragt die "rate-xx.dat": Was kostet eine Verbindung von "hier"
nach "007"
6. Die "rate-xx.dat" antwortet entweder:
kostet DM/AT/$/... : xxx
oder auch (genauso wichtig!!) : *keine*Ahnung*!
So w�rde mir das denke ich gefallen!
> Handy-Tarife zus�tzlich in die Zonendatenbank aufzunehmen lie�e ich mir
> ja noch einreden, aber Sondernummern wird echt zuviel.
Tarifm��ig ja, von der reinen Bezeichnung her denke ich eher nein.
> Was haltet ihr davon:
>
> es gibt ein getArea(), das in Zukunft (neben der Wildcard-Unterst�tzung)
> die Anzahl der �bereinstimmenden Stellen retouniert. Ich nehme an, eine
Her damit!
> �hnliche Funktion stellt auch zone.c zur Verf�gung. Nun braucht man
> eigentlich nur mehr beide Funktionen aufzurufen, und diejenige mit dem
> besseren Ergebnis zu verwenden:
Hallo! Wir arbeiten hier nicht nach statistischen/heuristischen Verfahren!
Es geht einfach darum, zu telefonieren!
Und dabei gibt es keine "ungef�hren" Zust�nde!
> Als Beispiel: Alle Inlandsvorwahlen werden vom getArea() nur als "+49"
> erkannt, also im Inland. getZone() kennt ja auch die Ortsvorwahl, und
Korrekt.
> liefert also das "bessere" Ergebnis. Eine Handy-Nummer wird vom
> getArea() als "+49172" erkannt, vom getZone() u.U. �berhaupt nicht =>
> also wird das Ergebnis vom getArea() verwendet.
Das ist aber jetzt ein "geht hoffentlich gut", oder?
> Auslandsnummern liefern nur beim getArea() ein Ergebnis. Sondernummern
> ebenfalls.
>
> Habe ich das Problem richtig erkannt?
Irgendwie bleibt mir das "JA!" im Halse stecken, ich wei� blo� nicht so
genau, warum ...
> 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]
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
------------------------------------------------------------------------
Visit Law.com for exclusive national and regional content,
online CLE Seminars, Practice Centers, Career Listings and
Expert Witness Directory.
http://click.egroups.com/1/6875/6/_/_/_/963501650/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
