[Bug 13351] Forwarding spec

[bugzilla-daemon at freedesktop.org]

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

Senko Rasic <senko at senko.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #16 from Senko Rasic <senko at senko.net> 2010-04-29 05:02:14 PDT ---
(In reply to comment #15)
> 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.

Changed. This also means I've had to do a few changes in the wording of the
spec, to use "condition" instead of "rule" - this distinction (a condition
being one component in the pattern that can trigger a rule, the other being
initial timeout) is somewhat blured by the fact that a condition can be used in
at most one rule.

> The ForwardingRules property maps conditions to what to do in those 
> situations, so it should be a dict not an array.
> [...]
> 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.”

Agreed, that seems the best to me.

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

Added.

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

Added.

> 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? :þ).

Changed so that 0 means immediately and MAX_UINT32 is the default, with an
option to change this once Maybe is added 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.

Makes sense. This also removes the need for MaxForwardingEntries.

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

Added. Although the forwardee handle is not actually a subject in this case
(it's more of an object), I think it makes sense to include their handle in
Actor, if it's known.

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

Wouldn't such change be backwards-incompatible with the current Group
behaviour? Anyways, we should probably have a new bug for discussing that so
the idea doesn't get lost in this one.

Updated branch available at:
http://git.collabora.co.uk/?p=user/ptlo/tp-spec-senko/.git;a=shortlog;h=refs/heads/forwarding

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