[sldev] Limiting the length of string inconsistently

[Strife Onizuka]

I prefer (c) as well, however annoying byte limits are (as compared to
character limits) they better represent the underlying limitations.

On 9/8/07, Kelly Linden <kelly at lindenlab.com> wrote:
>
> 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
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>