[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 #18 from Danielle Madeley <danielle.madeley at collabora.co.uk> 2010-11-30 15:08:54 PST ---
(In reply to comment #13)

> Connection.I.Voicemail might want to rever to ClientInterests, at least on some
> protocol the CM might need to do some extra work to poll for voicemail.

Agreed.

(In reply to comment #14)
> 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.

I agree. I'm thinking that I'll split this into Chan.I.Voicemail and
Chan.I.Voicemail.Retrieval

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

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. This means only
the token will be required for the request and all other retrieval properties
will be informational.

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

I think not (why would anyone want this?). But there could be an
Conn.I.Voicemail.InteractiveService property, which includes a request token.

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

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

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

I thought so, when you reconnect to the network, you might receive a bunch of
new messages.

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

I'm going to add a Removed:av argument. I don't think the client needs to
acknowledge a voicemail message, but there's an open question about whether we
need MarkRead/MarkUnread on Conn.I.Voicemail.

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

I agree. See above.

(In reply to comment #16)

> From the department of namespacing, Duration and AllowedDuration are a little
> ambiguous. My usual rule of thumb for good enough namespacing is: if I only
> tell you the member name and "it's in Telepathy", can you guess what it means?
> Out of context, I think Duration sounds more like a perpetually incrementing
> in-call counter, and AllowedDuration sounds more like a limit on the length of
> all calls (a rubbish PAYG tariff that disconnects you after 10 minutes as an
> incentive to upgrade to something more expensive, perhaps).

Would you prefer VoicemailDuration and AllowedVoicemailDuration?

(In reply to comment #17)

> Also, the voicemail number is stored on the SIM card. Some operators have
> neglected to save voicemailbox number the SIM card, so there must be a way for
> CM to indicate the voicemails are available even when it is not possible to
> create a meaningful channel request.

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

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