[Bug 24901] voicemail interface usable with at least GSM and Skype

[bugzilla-daemon at freedesktop.org]

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

--- Comment #23 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-12-01 06:47:15 PST ---
(In reply to comment #18)
> I'm going to change this such that only the token is required for the request.
> The CM can store whatever information in the token it requires.

If you're going to do that...

(In reply to comment #14)
> which properties are there so that the "you have new messages" UI can
> interpret them

... then these properties don't necessarily need to be properties (since
they're no longer part of the request), they can be an a{sv} of extra
information.

I assume that informational stuff like the sender is pretty irrelevant for the
observer/handler of the voicemail channel: if that's the case, then the
sender/timestamp/bees don't need to be properties on the channel at all.

The rationale for this:

(In reply to comment #3)
> Rob had the better
> idea of having a channel-request field in the mail notification; clients can
> just dump it into CreateChannel() in its entirety!

was that if the mechanism for retrieving voicemail is "dial 123", it would be
nice if the channel request that started the whole process contained {
TargetID: 123 }, for instance. If we're breaking that anyway (by using a
dedicated voicemail-token thing), there's no point in mapping things to
properties.

If you agree with that reasoning, then all of Voicemail.Retrieval except the
token can go away, and be replaced by a (token, a{sv}) pair in Conn.I.Voicemail
where the a{sv} is something like this:

{ 'sender': 42, 'sender-id': 'smcv at example.com', 'timestamp': now(),
  'duration': 65, 'message': 'dial 0800-your-ad-here to hear your voicemail' }

(In reply to comment #18)
> Would you prefer VoicemailDuration and AllowedVoicemailDuration?

I'd certainly prefer AllowedVoicemailDuration. If the above is persuasive, then
we don't need VoicemailDuration at all.

(In reply to comment #18)
> I agree. I'm thinking that I'll split this into Chan.I.Voicemail and
> Chan.I.Voicemail.Retrieval

VoicemailRetrieval would be conventional, FWIW - we don't generally do nested
namespaces within Chan.T.*, Chan.I.*.

> How do we indicate there are >=1 voicemails but the number is unknown?

I see you fixed this by having -1 indicate an unspecified nonzero number. That
seems entirely reasonable.

> I'm thinking in these instances, we should simply omit the VoicemailToken,
> meaning a request cannot be made.

If voicemails are a (token, info) tuple, you can't omit the token. Omitting the
token would break your API for DeleteVoicemail and VoicemailsRemoved, though,
so I don't think that's a good idea anyway.

Having non-unique tokens would also break DeleteVoicemail and VoicemailsRemoved
- if you've told me { token: "generic-voicemail-box", sender-id: "smcv" } and {
token: "generic-voicemail-box", sender-id: "sjoerd" }, how do you indicate that
the voicemail from me has been removed but the one from Sjoerd is still there?

Perhaps what you want here is to say that the tokens are mandatory, and in
addition, there'll be a RequestableChannelClass that allows VoicemailToken (and
you should specify its fixed properties) if and only if individual voicemails
can be received? (RCCs have to have a target handle type, so you may need to
use Handle_Type_None.)

For the GSM-style "generic inbox" case, you'd need some other mechanism -
perhaps a second property on VoicemailRetrieval, which can be
requestable-or-not? GenericVoicemailBox:b perhaps?

------------------------------------------------------------------

Comments on your spec HTML, assuming we discard VoicemailRetrieval and keep the
two Voicemail interfaces:

I think the intro blurb on Chan.I.Voicemail should specifically say that the
presence of this interface doesn't imply that this *is* voicemail, only that
you *might be* diverted to voicemail. Perhaps it should be called
VoicemailDiversion or VoicemailRecording, but perhaps that's too long.

RecordVoicemail should be tp:requestable="sometimes", and explain in the text
that it appears in the allowed properties of 1-1 StreamedMedia and Call calls
if and only if you can "go directly to voicemail" in this protocol.

VoicemailToken is tp:requestable="sometimes".

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