[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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikhail.zabaluev at nokia.com,
                   |                            |pekka.pessi at nokia.com

--- Comment #14 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-11-30 04:00:11 PST ---
I agree with Sjoerd's points - Chan.I.Voicemail is pretty confusing right now.
With it split in half, I think this'll be a reasonable shape to have as an
implementable draft.

It's also not completely clear which properties are "genuinely part of the
request", which properties are there so that the "you have new messages" UI can
interpret them, and which properties go both ways.

These interfaces would benefit greatly from some examples: I'd like to see what
would typically appear in Voicemails and requestable channel classes for a
protocol where you can retrieve voicemails individually by sender/token tuples
(Skype), and for a protocol where you can only retrieve voicemails by calling a
service and letting the user interact with it (GSM, presumably).

Do we want/need to support protocols where you *can* retrieve voicemails
individually, but there's also an interactive service you can call? If we do,
we'd want either a separate property for "this is what you request to reach the
interactive service", or a convention for "this request dict SHOULD be
supported, and should reach the interactive service".

Conn.I.Voicemail.NewVoicemails:
> If the server supports requesting individual voicemails, this signal
> will herald each unique voicemail, and these voicemails will appear
> individually in Voicemails.
>
> If the server does not support individual voicemails, this signal
> will be emitted each time there are new voicemails to be retrieved,
> but will contain a generic channel request. Only this generic channel
> request will appear in Voicemails.

This is quite nice, but the number of voicemails can't be state-recovered in
the "not individually addressable" case. A separate VoicemailCount property,
perhaps?

Is it actually useful for this signal to be plural, or could it be
NewVoicemail(a{sv})?

More cross-references between this, Voicemails and the "individually
addressable" flag would be useful.

Voicemails only has change notification in one direction: as currently spec'd,
the property seems to never shrink in size. It'd be good to have some way to
ack the notification/make the CM shut up, analogous to acknowledging a
Text/Messages message... hmm, have we just reinvented the N900's
voicemail-via-Messages? :-)

> If present, the protocol allows the user to request individual voicemails
> from the server

I think appending "non-interactively" would make this clearer...

> Otherwise, the voicemail channel is driven via some other method,
> e.g. DTMF  tones.

and "driven via some method requiring user interaction, e.g." here.

> ...retrieving individual voicemails, identified by their sender and a token.
> On those protocols, VoicemailToken and one of VoicemailSenderID or
> VoicemailSenderHandle must be included in channel requests

Why not set VoicemailToken to a composite thing which is informative enough on
its own? (VSI, VSH are still useful for UIs to display "you have two voicemails
from sjoerd and one from danni", though.)

> But now we have the MailNotification interface, these fit much better there.

No longer relevant :-)

> This property should only be requestable on Skype-style protocols.

What's a Skype-style protocol? I'd prefer "protocols with the
Supports_Retrieving_Individual_Voicemail flag, such as Skype" (or whatever you
actually meant, if my guess is wrong).

> [RecordVoicemail] should appear in the immutable properties, if the
> channel was requested with it.

That's tp:immutable="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.