[Ekiga-devel-list] Towards a new account system

[Julien Puydt <jpuydt free fr>]

Hi,

the future ekiga 3.00 will have SIP, H.323, IAX2, and hopefully some
XMPP support.

This raises a new need : how to manage the accounts ? The current system
probably won't scale well, so there is a need for some design here.

I had some ideas on it already, but a recent thread on gossip-devel
helped me get them straighter : it was on redesigning their account
system to work well with telepathy. I don't like their design ; feel
free to ask why if you care.

I also had in mind doing something like my addressbook system
proposition : there should be an easy way to push things in external
plugins if needed.

So let's first see what we can put in any account, whatever the protocol
may be :
1) a name ;
2) a state (two established states : connected and disconnected, and two
intermediary state : connecting and disconnecting) ;
3) a status (some string to say what happens, say "disconnected",
"connecting", "handshaking", "authenticating", "connected" -- something
more fine-grained than the state to show to the user, like "disconnected
-- host not found!") ;
4) a connect-on-startup boolean.

Basically, that means an account would be an object, with the following
api :
typedef enum {
  GM_ACCOUNT_STATE_DISCONNECTED,
  GM_ACCOUNT_STATE_CONNECTED,
  GM_ACCOUNT_STATE_CONNECTING,
  GM_ACCOUNT_STATE_DISCONNECTING
};

const gchar *gm_account_name (const GmAccount *account);
guint gm_account_get_state (const GmAccount *account);
const gchar *gm_account_get_status (const GmAccount *account);
gboolean gm_account_should_connect_on_startup (const GmAccount *account);
void gm_account_connect (GmAccount *account);
void gm_account_disconnect (GmAccount *account);

and the following signal : "updated".

This should already be enough to present existing accounts pretty nicely
to the user.

Now, how to manage accounts in a more generic way, ie : create, modify &
delete them ?

I would organize things like this :
- an accounts-core object has an oversight over all accounts
- through a list of objects of type gm-protocol,
- which manage each gm-accounts.

Let's try to see what it would give on some use cases :

(I) AVAHI

We would have an avahi plugin. This plugin would provide on one hand
addressbooks (for local H.323, SIP, IAX2, etc contacts) [this is already
done in the sample code I wrote for addressbooks], and on the other
hand, accounts, which would be exporting ourselves as H.323, SIP, IAX2
for others to see.

(II) SIP

This would come as builtin, and would contain all the usual accounts now
(ekiga.net for example).

(III) Creating an account

The account window would of course allow to create a new account. For
this, it should be able to query the accounts-core for a list of
possible protocols, and let the user choose one (with a nice description
of each choice so the user isn't drown).

Once the user has chosen the protocol, since ekiga now knows the
protocol, it is easy to present the user with a form or assistant with
exactly the right questions asked, with exactly the right indications to
make this un-painful.

(IV) Modifying an account

Again, easy : we know the account, we can show the right form.

(V) Parallel idea on account

Since an assistant is perhaps too much for a simple account, perhaps we
could make the protocol create an account with default parameters, then
trigger the edition of this account ?

Something like :

account = foo_account_new (blah, blah, blah);
editor = gm_account_editor_new (account);
result = gm_account_editor_run (editor);

if (result == GTK_RESPONSE_CANCEL) /* user changed his/her mind */
  g_signal_emit_by_name (account, "delete");
else
  gm_protocol_add_account (self, account);

(VI) Showing a progress window on startup

We could have something very much like gaim's progress window on
startup, with the status message shown.

There would be no nice progress bar since I didn't add in a way to know
how many steps are needed to go to connected state : I thought it was
kludge.

It would close itself automatically when all accounts get connected
correctly, but would write the status message in red when one of them
goes directly from GM_ACCOUNT_STATE_CONNECTING to
GM_ACCOUNT_STATE_DISCONNECTED : in case of an error.


Comments ?

Snark