[sldev] Limiting the length of string inconsistently

[Kelly Linden]

First, for those that haven't looked, group notices are IMs.  The path
of an IM looks something like:

Viewer -(udp)-> Sim of sender *-(tcp)-> Sim of receiver -(udp)-> Viewer
                              |
                              *-(udp)-> Dataserver -(mysql)-> DB

The dataserver is actually on the same host as the sim of the sender. 
The key point here is that several pieces of this journey are UDP which
means we must contend with MTU.  We are usually pretty conservative
about our MTU packet size, and 1200 bytes sounds about right once you
factor in the other meta data that travels with the message.

There is a new system in place for each of the UDP steps above, but IMs
do not (yet) use them:
* For viewer -> sim there is the caps system
* For sim -> dataserver a key scaling project currently in progress is
to replace the dataserver with a set of light weight and scalable  web
services.  These use TCP/IP and not UDP.
* For sim -> viewer there is the 'event queue'

You are right that none of these can be completed by open source devs
right now.  The second one (dataserver) will get handled very soon, and
the other two may not be too difficult.  However, until they are done
(and priorities being what they are I'm not sure the time table for
that) I think (b) or (c) are the viable options.  I kind of prefer (c)
since it is more flexible and doesn't limit more than actually needed.

 - Kelly

Lawson English wrote:
> Top-posting: this issue applies to just about any bit of UTF-8 text,
> including llSetText or any other text that has an arbitrarily short
> built-in limit. I haven't tested Japanese kanji with GUI elements like
> dialog text-entry, but I suspect it applies there as well.
>
>
> Alissa Sabre wrote:
>> I filed a new JIRA issue, VWR-2367.
>>
>> It is on the maximum message length of a Group Notice.  The point is,
>> that, when editing the notice, the maximum length of the message is
>> limited by the number of _characters_.  When the notice is sent, the
>> lower messaging layer checks the maximum length by the number of
>> _bytes_.
>>
>> When editing, the maximum length is 511 characters.  The lower layer
>> limits the maximum by 1200 bytes (including some overheads).  Since,
>> one Japanese character occupy three bytes in UTF-8, Japanese Group
>> Notice messages with more than about 400 characters are truncated when
>> sent.
>>
>> I can imagine three approaches to fix it.  Which fix is best?  I want
>> to know your opinions.
>>
>> (a) Extend the messaging maximum to cover the worst case maximum.
>>     Because, a character can occupy four bytes in UTF-8 as a maximum,
>>     511 characters can be up to 2044 bytes.  Enlarge the lower layer
>>     limit to this value (plus some overhead.)
>>
>> (b) Reduce the UI (editing) limit to the value that is guaranteed to
>>     pass the lower layer limit in worst case.  That is 1200 (minus
>>     some overhead) divided by four, i.e., around 250.
>>
>> (c) Add a feature to a UI component (LLTextEditor) to limit the
>>     maximum size in bytes as opposed to in characters, and set that
>>     limit to a value around 1000.
>>
>> If the way we should go is (b) or (c) above, I can write a fix.
>> However, if the correct fix is (a), I don't think it's doable by open
>> source developers, since I guess the server-side code should be
>> updated in sync.
>>
>>     Alissa Sabre
>> --------------------------------------
>> Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
>> http://pr.mail.yahoo.co.jp/toolbar/
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>
>>   
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html