[Telepathy] forwarding spec questions

[Andres Salomon]

On Wed, 17 Mar 2010 10:42:50 +0100
<mikhail.zabaluev at nokia.com> wrote:

> Hi,
> 
> > -----Original Message-----
> > From: telepathy-bounces at lists.freedesktop.org [mailto:telepathy-
> > bounces at lists.freedesktop.org] On Behalf Of ext Andres Salomon
> > Sent: Tuesday, March 16, 2010 8:20 PM
> > To: telepathy at lists.freedesktop.org
> > Cc: Sjoerd Simons
> > Subject: [Telepathy] forwarding spec questions
> > 
> > Regarding http://bugs.freedesktop.org/show_bug.cgi?id=13351 (the
> > forwarding spec), I'm trying to determine just how much the spec
> > needs to support.  The discussion of scripts is much more complex
> > than the GSM call-forwarding model.  If that's something that
> > telepathy needs to support, what kind of API is envisioned?
> 
> For the Connection interface, it's enough if we can do this:
> 
> property SupportedForwardingConditions: au, read-only
> 
> property ForwardingRules: a(ua(uu))
> 
> method SetForwardingRule(u: Forwarding_Condition, a(uu):
> Forwarding_List) -> a(uu)

What happens if I attempt to call SetForwardingRule(Busy, {0, 231}) when
there's already an entry in the Forwarding_List array for Busy?  Does
the old entry get overwritten, or can both Busy entries co-exist in the
array?


> 
> signal ForwardingRulesChanged: a(ua(uu))
> 
> enum Forwarding_Condition: u {
>     Unconditional,
>     Busy,
>     NoReply,
>     NotReachable
> }
> 
> struct Forwarding_List_Entry {
>     u: Timeout,
>     u: Handle,
> }
> 
> The timeout is for how many seconds should the service wait (on the
> original call, or a previous forwarding attempt) before attempting
> forwarding to that handle. It can be 0 if the client does not care
> and lets the implementation decide, and it's reported back as 0 if
> the service does not advertise definite timeouts (there could be a
> feature flag property about that, too).
> 
> I'm not certain of how the conditional rules should supplement each
> other. Should NoReply also work if the subscriber is not reachable
> and the rule for NotReachable is not set? Or vice versa? Will
> anything supplement Busy? Or should it be at the discretion of the
> connection manager, which will be obliged to advertise all effective
> rules as apply to each condition?
> 

Unconditional overrides everything else.  NotReachable is a specific
case, and shouldn't (in theory) apply to Busy/NoReply.  If the GSM
phone is on and in service range, Busy and NoReply should be the only
remaining options.

I would think that this maps to VOIP calls as well; NotReachable
implies the local user is not online (if the protocol doesn't allow us
to see whether or not a user's online, then NotReachable will never be
triggered).  If the user is online and is capable of receiving calls,
then Busy and NoReply are all that remain.

I don't think it's worth attempting to guess what the user has in mind;
the UI can do that, depending upon what kind of functionality it
exposes.  If NotReachable is unset and the user is offline, I don't
think NoReply should be substituted.  Note that these may be
implemented (on the protocol level) completely separately.
NotReachable may be registered with a remote service, while NoReply may
be something that the CM takes care of if the local user doesn't
respond.

In the case where the underlying network services automatically
supplement the forwarding rules, this should either be turned off, or
the CM can make that explicit (ie, setting NoReply while NotReachable is
unset results in a ForwardingRulesChanged signal that has *both* set;
likewise, setting Unconditional with nothing else set might raise the
ForwardingRulesChanged signal w/ every forwarding rule set).