So, we’re hitting the point where our current work is nearing closure with the Modular Rex code - the biggest thing worth noting right now is some new extensions to allow extra rex properties to be attached to objects. This wasnt implemented quite how I originally envisioned - I ran into some issues where subclassing something simply wasnt practical. While it was possible to do - the number of workarounds required to keep it running in the long term pushed the work in another simpler direction.
The above shows an object stored in ModRex with the additional properties set — to handle this, we’re actually using a second Entity array inside of a module, which monitors agent connections and feeds the array to anyone who can parse it (ie Rex-derived clients). Why not subclass? The short answer here is we ‘construct’ SceneObjectPart classes in a wide variety of places - including serialisers. Replacing all those references with a ISOPFactory class required making a few too many changes for me to be comfortable with. I’d argue it needs to be done from an architectural perspective, however we’re also discussing doing a SceneObject overhaul, and it would be foolish to do such a work when the replacement is nearby.
So - what still needs to be done? Well there’s still the matter of the CommsManager - right now we can use the local comms manager to access inventory ala standalone-mode, however this does require a degree of database synchronisation between your OpenSim UserDB, and the authentication server. In the long term some bigger changes are needed - most notably, I would like to ‘do away’ with the use of UUID’s as usernames and move to the more logical (and unique) Rex Account schema (user@host).
Finally - there’s some nifty parts to ModularRex which I hope to expose to configuration options soon, and that’s breaking up the features more thouroughly. There’s a number of people who want to use Rex features like their avatars and/or meshes, but dont want to rely on the Rex Authentication system — internally this is quite possible to do and once the main pieces are all signed off, that’s one area we’d like to work on.
Update #1: Better Screenshot
OK, so I managed to get OpenSim’s asset system working with modrex again, so Meshes are now sort-of working with modrex (albeit buggy). [Clicky]
Adam,
thanks for all the work on modrex!
Coincidentally, I published a piece a few days earlier on using the rexdata panel with the Python CompObj library to supply configuration parameters in inifile format.
While browsing the code I noticed that there’s a hard-coded limit of 3000 characters on the rexdata blob in the original code and in modrex. It seems a bit arbitrary and low. The maximum blob sizes in the supported databases are:
SQLite: 2**31-1
MySQL: practical limit is 100’s of MBs due to triple copies being maintained
MSSQL: 2GB
I’d like to see the size lifted to a larger value, perhaps configurable in OpenSim.ini. What are your thoughts on this?
– Peter
Peter Quirk
6 Jan 09 at 8:37 pm
Where is this value hard coded? It may be in a piece of code which was ported directly. I actually don’t think I have done the RexFreeData blob yet, only the RexPrimData blob (which should never get close to that size).
That being said, if this is something that is transmitted to the viewer - factor bandwidth into your calculations (obviously if you reaaaally want to you should be able to, but it’s worth keeping in mind)
Adam Frisby
6 Jan 09 at 8:59 pm
In the original code, in SceneObjectPart.cs we have:
private string m_rexData = String.Empty;
public string RexData
{
get { return m_rexData; }
set
{
if (value.Length > 3000)
m_rexData = value.Substring(0, 3000);
else
m_rexData = value;
ScheduleRexPrimFreeDataUpdate(true);
}
}
This is implemented similarly in modrex.
Peter Quirk
7 Jan 09 at 3:01 am
Aha, alright. Hrrm.
This does come down to a bandwidth issue as that ‘freedata’ is used for sending what I’ve been told, metadata and that sort of information about objects. However, from my own knowledge of further down, 3000 is too big. It will fail at about 1300 or so due to the normal packet MTU of 1500B.
That data wont be split up and multipacketed either, so if there’s a need to have large metadata fields about objects, perhaps the way to go is to either implement a multipacket version, or move the request over to HTTP.
Adam Frisby
7 Jan 09 at 8:53 pm