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

[Damien Sandras <dsandras seconix com>]

My idea was to put accounts in the contacts list, as a special contact,
like it was done in the good old Gabber.


Le lundi 02 octobre 2006 à 21:30 +0200, Julien Puydt a écrit :
> 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
> 
> 
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
-- 
 _      Damien Sandras
(o-     
//\     Ekiga Softphone: http://www.ekiga.org/
v_/_    FOSDEM 2006    : http://www.fosdem.org/
        SIP Phone      : sip:dsandras ekiga net
                         sip:600000 ekiga net