[Bug 13351] Forwarding spec

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=13351

--- Comment #15 from Will Thompson <will.thompson at collabora.co.uk> 2010-04-27 06:05:52 PDT ---
>From http://lists.freedesktop.org/archives/telepathy/2010-April/004452.html:


Our consensus was that this interface is the right shape, but some types 
are not ideal, poorly named, etc. In particular:

The Forwarding_Rule enum isn't the type of a rule, it's the type of a 
condition to apply rules in. So it should be called Forwarding_Condition 
or similar.

The ForwardingRules property maps conditions to what to do in those 
situations, so it should be a dict not an array. So we get:

   ForwardingRules: a{ u — Forwarding_Condition
                  → a(uu) — Forwarding_Rule_Entry[]
                     }

There's ambiguity as to what the timeout in a forwarding rule entry 
means. According to the example, it means "the time to take before 
redirecting to this handle"; according to the struct definition, it 
means "the time to wait for this handle to answer before failing over to 
the next rule".

We could bike-shed which way round it should be... In the first case, we 
have no way to specify how long to wait for the handle in the last rule 
to answer before giving up; in the second case, we have no way to 
specify how long to wait for the local user to answer before trying the 
first rule. Perhaps we should take the second definition, and change the 
type of ForwardingRules further into:

   a{ u — Forwarding_Condition
    → ( u — initial timeout,
        a( u — handle,
           u — timeout for this action
         )
      )
    }

Then for example, the following value of ForwardingRules:

   { Busy: (30 seconds, [ (handle 3, 15 seconds)
                        , (handle 5, 20 seconds)
                        ]
           ),
     ...
   }

would mean: “if I'm on another call, keep the call waiting for 30 
seconds. If I don't answer the new call, redirect it to handle 3. If 
they don't answer within 15 seconds, redirect it to handle 5. Finally, 
if they don't answer within 20 seconds, give up.”

We should say what happens if your provider doesn't support call 
waiting, but you specify a Busy action with a non-zero time: the time is 
ignored.

In ‘a user's status is set to "Don't Bother Me"’, link to simple presence.

0 shouldn't mean default. 0 should mean "immediately", and MAX_UINT32 
should be the default. Or something (maybe make it signed so we can use 
-1? Maybe introduce maybe types to D-Bus? :þ).

SupportedForwardingRules should be renamed SupportedForwardingConditions.

How would we deal with Busy being handled locally, and NotReachable 
being on the server? Specifically: the server may only support one 
contact for NotReachable, but the local impl. can support >1. Maybe 
SupportedForwardingConditions should be an a{u: Condition → u: 
max_count} mapping supported conditions to how supported they are.

Side point: we need an error condition which says "this call ended 
because it was forwarded". (Do we want to say to whom?) Add an element 
to Call_State_Change_Reason.

How do we represent a call being forwarded immediately? It's easy with 
Call: we just announce a channel with the state already set to Ended. 
Call channels don't close themselves, so it'll be dispatched as normal. 
Hooray! Dancing in the streets, baked treats all round. Maybe we can 
clone this pattern onto the Group interface so it can deal with being 
booted immediately from a chat room.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.