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