Re: [Telepathy] forwarding spec questions
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.zabal...@nokia.com wrote:
Hi,
-Original Message-
From: ext Andres Salomon [mailto:dilin...@collabora.co.uk]
Sent: Wednesday, March 17, 2010 6:47 PM
To: Zabaluev Mikhail (Nokia-D/Helsinki)
Cc: telepathy@lists.freedesktop.org; sjoerd.sim...@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..
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] forwarding spec questions
Hi,
-Original Message-
From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy-
boun...@lists.freedesktop.org] On Behalf Of ext Andres Salomon
Sent: Tuesday, March 16, 2010 8:20 PM
To: telepathy@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)
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?
--
Mikhail
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] forwarding spec questions
Hi,
-Original Message-
From: ext Andres Salomon [mailto:dilin...@collabora.co.uk]
Sent: Wednesday, March 17, 2010 6:47 PM
To: Zabaluev Mikhail (Nokia-D/Helsinki)
Cc: telepathy@lists.freedesktop.org; sjoerd.sim...@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
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
