[Telepathy] forwarding spec questions

[mikhail.zabaluev at nokia.com]

Hi,

> -----Original Message-----
> From: ext Andres Salomon [mailto:dilinger at collabora.co.uk]
> Sent: Wednesday, March 17, 2010 6:47 PM
> To: Zabaluev Mikhail (Nokia-D/Helsinki)
> Cc: telepathy at lists.freedesktop.org; sjoerd.simons at collabora.co.uk
> Subject: Re: [Telepathy] forwarding spec questions
> 
> > 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?

I think for simplicity sake, it should be overwritten. As well as any other rule that will effectively be changed by the implementation when setting this rule.
Maybe there is little point in reflecting the effective rule in the return value as I indented (as there is already a signal for that), so the return value could get the replaced rule.

> > 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.

Sounds OK to me. But I'd like to keep a provision for the service to change any other rules as a side effect of setting one particular conditional rule. There might be protocols that cannot distinguish some of the proposed conditions. Also, setting Unconditional could explicitly remove all conditional rules as reflected by the ForwardingRulesChanged signal.
 
> 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;

Right.

> likewise, setting Unconditional with nothing else set might raise the
> ForwardingRulesChanged signal w/ every forwarding rule set).

That, or just one Unconditional rule survives. This way will make the job of a UI client easier.

Some finer points about the proposal:

- Does setting an empty list nullify the rule, or do we need a separate method to clear?

- There should be a property to limit the number of entries per list, which can be 0 (or MAXUINT32?) if there's no explicit limit, and 1 if the protocol does not deal with lists. The CM may have the right to shorten the list, as long as it is properly signalled.

- As mentioned before, a Boolean property to tell if timeouts are supported.

-- 
  Misha