Re: [GnomeMeeting-devel-list] Dbus' future in gnomemeeting

[Julien PUYDT <jpuydt free fr>]

Julien PUYDT a �it :
> ======== IMPROVEMENT IDEAS ========
>
> - call tokens should become the norm, and the interface should be about 
> using and knowing about them ;
> - call tokens should have a broader range of states : calling, 
> established, transferred, paused, stopping or stopped come to mind ;
> - a single CallInfo signal could be enough ; such a signal would always 
> come with a call token and its new state, but could also come with more 
> information ;
> - AddCall and DeleteCall disappear : a call is created when a CallInfo 
> about it being somehow live comes, and dies when its new state is 
> "stopped" ;
> - it should probably be possible to create/stop/pause/whatever media 
> streams within a call (useful for integration with an IM client for 
> example...) ;
> - send the state as an integer.

There has to be a method call to get the list of call tokens :
* "GetCallsList"
 in    : nil
 out   : list of strings (call tokens)

and a series of method calls to act on them :

* "Connect"
 in    : string (url)
 out   : string (call token)
* "Disconnect"
 in    : string (call token)
 out   : nil
* "PlayPause"
 in    : string (call token)
 out   : nil
* "Transfer"
 in    : string (call token), string (url)
 out   : nil

probably a series of getters too :
* "GetState"
 in    : string (call token)
 out   : int (state : calling, stopped, etc)
* "GetRemoteName"
 in    : string (call token)
 out   : string (remote name)
* "GetRemoteClient"
 in    : string (call token)
 out   : string (remote client software)
* "GetRemoteURL"
 in    : string (call token)
 out   : string (remote url)
* "GetProtocol"
 in    : string (call token)
 out   : string (protocol used : SIP, H323, etc)

there should be a way to signal changes in the call states :
* "state-changed"
 data  : string (call token), int (state of the call token)

there should be signals associated to call tokens' data :

* "name-info"
 data  : string (call token), string (remote name)
* "client-info"
 data  : string (call token), string (remote client software)
* "url-info"
 data  : string (call token), string (remote url)
* "protocol-info"
 data  : string (call token), string (protocol used)

The basic idea behind this organisation is the following use-case for 
the gm_remote :
- gnomemeeting places a call ;
- it emits a "state-changed" signal of "calling" state (in integer form) 
on that call's token ;
- the remote can already show the call, although it is too early to know 
anything about it -- it knows it is a new call because it didn't know 
that call token ;
- when gnomemeeting gets some data (remote name, remote client, etc), it 
emits the corresponding signal ;
- the remote can fill in the blanks gradually ;
- the call gets established : gnomemeeting emits "state-changed" with 
the "established" state ;
- the remote knows about it and can display this information ;
- the call ends : gnomemeeting emits "state-changed" with the "stopped" 
state ;
- the remote deletes the call from its list.

The getters are useful only in the case where the remote got to know 
about the calls through GetCallsList (for example because it was 
launched after gnomemeeting). They should probably return NULL (or 
"stopped" for the GetState method) when asked about an unknown token.

Would that fly as a beginning ?

Snark