Bug 36011

Summary: Add Chan.I.SMS.GetLength()
Product: Telepathy Reporter: Danielle Madeley <danielle>
Component: tp-specAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium CC: nicolas
Version: git masterKeywords: patch
Hardware: Other   
OS: All   
URL: http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/get-sms-length-36011
Whiteboard: review+
i915 platform: i915 features:

Description Danielle Madeley 2011-04-05 17:24:23 UTC
It is difficult to know how long an encoded SMS is going to be. It's not possible for the client to know what encoding mechanism the CM will use.

Proposing the addition of a new method: GetLength(s) -> (uui)

~ In ~
s: proposed SMS content
~ Out ~
u: SMS chunks required
u: remaining chars for chunk
i: estimated cost (or unknown as defined in Conn.I.Balance)
Comment 2 Danielle Madeley 2011-04-05 19:39:08 UTC
This method needs a mechanism to indicate the message will be truncated because it would require more chunks than we can send. Not sure how this should happen.
Comment 3 Will Thompson 2011-04-13 11:16:23 UTC
This looks reasonable. I think there should be a recommendation that clients SHOULD not call this method after every keystroke (I assume Empathy would call it at most once a second or something?).

In the NotImplemented error annotation, suggest that clients fall back to estimating the number of chunks internally. (The N900's UI, for instance, used an SMS library to determine this in-process.)

Oh! for Maybe types.

I reluctantly think that Content should be aa{sv}: Ring, at least, can send vCards.

Proof-reading nit-picks:

+            This method allows the client, without any knowledge of the
+            encoding mechanism to provide length details to the user.</p>

I think you're either missing a comma, or you should move “to provide length details to the user” in place of the comma.
Comment 4 Danielle Madeley 2011-04-13 17:54:31 UTC
(In reply to comment #3)
> This looks reasonable. I think there should be a recommendation that clients
> SHOULD not call this method after every keystroke (I assume Empathy would call
> it at most once a second or something?).

"Clients SHOULD limit the frequency with which this method is called and SHOULD NOT call it for every keystroke. Clients MAY estimate the remaining size between single keystrokes." ?

> In the NotImplemented error annotation, suggest that clients fall back to
> estimating the number of chunks internally. (The N900's UI, for instance, used
> an SMS library to determine this in-process.)

"Clients MAY choose to make their own estimation." ?

> I reluctantly think that Content should be aa{sv}: Ring, at least, can send
> vCards.

Good point. Also in some magical future, MMS.

> I think you're either missing a comma, or you should move “to provide length
> details to the user” in place of the comma.

Yes.

Any idea how to best represent that a message will be truncated? Perhaps add a b:Truncated, where, if true, Remaining_Chars indicates how many characters will be truncated. Alternatively, make Remaining_Chars signed, and make negative represent the number of characters that will be truncated.
Comment 5 Danielle Madeley 2011-04-13 17:55:31 UTC
(In reply to comment #4)

> Any idea how to best represent that a message will be truncated? Perhaps add a
> b:Truncated, where, if true, Remaining_Chars indicates how many characters will
> be truncated. Alternatively, make Remaining_Chars signed, and make negative
> represent the number of characters that will be truncated.

Problem with this second solution when we know the message will be truncated, but not by how much.
Comment 6 Will Thompson 2011-04-20 12:00:18 UTC
(In reply to comment #5)
> (In reply to comment #4)
> 
> > Any idea how to best represent that a message will be truncated? Perhaps add a
> > b:Truncated, where, if true, Remaining_Chars indicates how many characters will
> > be truncated. Alternatively, make Remaining_Chars signed, and make negative
> > represent the number of characters that will be truncated.
> 
> Problem with this second solution when we know the message will be truncated,
> but not by how much.

So how about:

GetLength ( aa{sv}: proposed content )
  → ( u: chunks to be used
    , i: remaining chars for chunk
    , i: estimated cost
    )

If the second returned thing is negative; the message will be truncated. If it's MIN_INT32, we don't know where it got cut off; if it's anything else, that's how much you'll lose.
Comment 7 Danielle Madeley 2011-04-20 16:27:28 UTC
Works for me. Branch updated.
Comment 8 Will Thompson 2011-04-21 11:06:32 UTC
Looks great, merge away!
Comment 9 Danielle Madeley 2011-04-26 16:50:05 UTC
Done!

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.