[Telepathy] forwarding spec questions

[Andres Salomon]

Thanks for the input!  I've uploaded an initial draft here -

http://git.collabora.co.uk/?p=user/dilinger/telepathy-spec;a=shortlog;h=refs/heads/forwarding

I still need to make the references to various enums/functions/signals
proper links still.

I have some comments below (after this, let's take further
discussion to the bug -
http://bugs.freedesktop.org/show_bug.cgi?id=13351 ).



On Wed, 17
Mar 2010 18:26:45 +0100 <mikhail.zabaluev at nokia.com> wrote:

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


I noted this in the spec, saying that one shouldn't modify other rules,
but if forced to.. multiple Changed signals should be raised.


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

I think empty list is fine.  I was quite tempted to change the
rules array to a struct for clarity's sake (if each rule is an element
in the struct, it's pretty clear that changing a single element will
overwrite the previous value), but held off for two reasons;
1) the dbus C api for structs is a pain, and
2) I can imagine wanting to add other rules.  If we expand the enum and
use an array for the rule list, I don't think we'd have ABI problems.
If we have a struct that's being passed around, I'm not sure what the
ABI situation would be like.



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

ACK.  I left the right-to-shorten-the-MaxForwards bit  out; do you have
a use case for that sort of thing?


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

I mentioned that timeouts may be ignored by the CM (due to a number of
reasons).  Do you think it's worth attempting to tell the client if
they're used or not?  In some cases, I can imagine the CM itself not
even knowing..