Bug 36011

http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/get-sms-length-36011

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.

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.

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

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

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

Works for me. Branch updated.

Looks great, merge away!

Done!