Re: [Ekiga-devel-list] Handling ordinary phone numbers ( Yet Another Approach)

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

Hi,

Thanks, Alec, for this.  Let's try to check it in while it is "fresh", 
otherwise it will be forgotten and the chances to be integrated are small.

Also, let's wait with the check in a few days (until Tuesday?) for other 
people comments.

(I welcome the "make easy the user work" subject; there is room here for 
other sub-domains too, we will speak later about that.)

Alec Leamas wrote:
> Trying to explain this once again, hopefully better. Questions in the 
> end...
>
> The problem I try  to solve is that users typically stores telephone 
> numbers, often formatted and without countrycode, whereas Ekiga today 
> requires a complete URL to place even an ordinary PSTN call. This makes 
> the basic process to call a PSTN number hard, user has to manually 
> convert e. g., '070-543 22 11' to sip:+46705432211 sip diamondcard com 
>
> I have written a piece of code which converts numbers to sip: urls. It's 
> partly a question of handling missing country codes, partly  to remove 
> formatting characters as in '070- 543 11 22'. This code of course 
> requires some configuration to define user's own countrycode etc. (all 
> in total four values). It generates default config values usable for 
> most users, and seems to work. It has the potential to let users just 
> enter e. g., 070-543 22 11 in Ekiga to place a call instead of a 
> complete URL.
>
> My problem is if/how to integrate this into Ekiga. More precise, I need 
> help to integrate it. The Ekiga code is big, and although I think I'm 
> able to produce a set of patches, I will at least need help with where 
> in the code I should begin, and certainly other things as well. I really 
> can't be on my own in this, it's to much for a newbie...
> So: first question: Would this overall be a Good Thing, something that 
> makes Ekiga more usable, and thus worth some effort?

I agree.

> Second question. I have done a simple plan: 
> http://mumin.dnsalias.net/ekiga-callto-ui/patches.html. Is this reasonable?

I agree.

> Third question. There is some UI impact, described in 
> http://mumin.dnsalias.net/ekiga-callto-ui/index.html. Does this seems OK?

For the moment, let's just do nothing (the current error is shown). 
Later, we can add a menu entry, or a tab in preferences etc.

> Last question: Depending on the outcome of the other questions, how 
> should I proceed with the first patch, to integrate a set of new source 
> files related to PSTN management into Ekiga?

There are three files involved (Pstn* and .csv); I would propose to use 
PTRACE from ptlib; as for assert, isn't possible to use classical asert?

The first thing is to add a hook when the user clicks on green button. 
Later, we will add a hook for adding in dbus, roster etc., as you wrote. 
 I see in the bug report there are several things involved, such as 
PresenceCode; so is it there to add this hook?  The change to ekiga 
current code should be very small, only 2 lines (call your pstn file and 
replace the URL bar value).

In fact, all your work can be resumed like this: when the user pushes 
the green button (or dbus, roster etc.), the number in the URL bar is 
transformed, that's all, isn't it?

> Some background material: usecases defined in a few "stories:" 
> http://mumin.dnsalias.net/ekiga-callto-ui/stories.html

I agree.

Additionally, I have some comments:

1. Note that ekiga already adds the suffix (it shows it in the combobox,
but it adds it too)

2. What happens when you have two accounts?  Which one does it choose? 
(We can think about this later, let's do it step by step, as you propose.)

3. How does this integrate with ekiga-callto program/package, i.e. who
does the url changing, ekiga-callto or ekiga itself?

4. I do not know curl well, why is it needed?  What should you retrieve? 
 Does regex create problems on windows or macos?

Do you think it is useful to add a wiki page and add there the steps we 
will to implement, to avoid errors later?  Or do you prefer to push your 
current patches, in one step or step by step?

--
Eugen