Descriptions aren't really intended for data-storage, and there are other ways that that data can be lost. If you need to store more than 127 characters you should use another method, such as having the object e-mail the information to itself, or use llHTTPRequest and an outside database.

Is it 127 characters long? That's fine.

Then change the wiki so that people don't waste their time in this thing!

Since comments are transmitted to the client (tooltip hovertext) these 100 prims alone would create an overhead of 800k data to be loaded assuming each character of the comment only uses 8 bits.

800k for 100 prims.

If all 15,000 prims in a sim would have that much comment you'd have to download a whopping 114 megabytes of data.

So there is definitely abuse potential.

(Haravikk- There are rather large flaws with your alternative suggestion: 1) You can't send email to an asset uuid key you don't yet know. 2) Being able to retrive object-specific data from an external database (assuming you're luck or rich enough to have one) ... also requires using llSetObjectDesc() in order to store some sort of unique object identifier so that when the key changes.. the object still knows what to ask for. Both ideas may work in limited situations but they're more of a kludge than relying on llSetObjectDesc().)

llSetObjectDesc() is valuable and necessary to preserve essential script data across (RESET) (SAVE) (Shift-Drag-Copy) and whatever other operations cause a prim's script state to be utterly and unavoidably lost.

... I would prefer a hidden prim attribute that was not shown on the edit UI in which a "chat length text string" amount of data could be stored and retrieved, lacking that, llSetObjectDesc() has to suffice.

Being unable to rely on anything more than 127 characters is insanely frustrating.