Recent changes to feature-requests

Allow for arbitrary HTTPS connections with self signed certificates

2013-06-07T10:05:59.458000Z

Currently the core library only knows of the two self signed certificates for the Lindenlab server to allow to connect to them without causing a security exception.

This improvement would add an additional callback mechanism to the login operation that would be triggered when a security exception occurred during HTTPS handshake because of untrusted certificates. The callback provider would then have to query the user if the certificate should be accepted anyhow or if the connection should be refused. In case of acception there would be the choice to accept it just for this connection request or to add the certificate exception to some application specific keystore to be used in future connection attempts to this server.

#2 make message parser dynamic

2013-05-13T20:52:31.489000Z

Group: --> Dynamic Protocol Handling

#1 Primitive object information duplication

2013-05-13T20:51:59.661000Z

Group: Simple JAVA GUI --> Dynamic Protocol Handling

#1 Primitive object information duplication

2013-04-22T07:17:12.099000Z

Description has changed:

Diff:

--- old
+++ new
@@ -1 +1 @@
-There seems to be quite a bit of duplication between the information in libomv.primitives.Primitive and libomv.assets.AssetPrim.PrimObject. We should try to combine these informaitions in one place if possible.
+There seems to be quite a bit of duplication between the information in libomv.primitives.Primitive and libomv.assets.AssetPrim.PrimObject. We should try to combine these informations in one place if possible.

Group: --> Next Release (example)

make message parser dynamic

2012-08-29T07:05:30Z

Instead of creating all the UDP and CAPS message classes and adding them to the source code, we should look at doing the building and parsing at runtime instead. The ProtocolManager to parse the message_template.xml file already exists for the mapgenerator and could be reintegrated into the core library. Basically there would be a message serializer class for CAPS and UDP each which allows to construct and parse the message streams at runtime based on the Block Name and Element Name string. A static MessageElement class would contain constants for those names. When a message arrives only its header gets parsed to determine the message type and then the message is passed along in the system. The final receiver then uses the message serializer methods to retrieve the elements based on Block Name, Element Name and Block Number. In the case of UDP messages the message serializer queries the Protocol Manager to locate the correct offset in the stream, in case of CAPS messages the serializer directly references the OSD data elements.

Alternatively on receiving an UDP messsages it could be directly deserialized into OSD data and then each received message is basically just an OSD data.

Some tests need to be done to find out what the performance consequences for each of these are. The first to only deserialize the message on actual interpretation avoids the overhead of deserializing any and all messages in the simulator loop, moving that burden to the actual consumer, but it avoids almost all work for messages that may never be consumed.

The second solution to deserialize everything to OSD makes everything more uniform, but leaves the deserialization work in the simulator receiver loop and uses up CPU and memory to create potentially large object hierarchies that may be never actually consumed.

make message parser dynamic

2012-08-29T07:05:30Z

Ticket 2 has been modified: make message parser dynamic
Edited By: Frederick Martian (fredmartian)
_milestone updated: '' => u'Dynamic Protocol Handling '

Primitive object information duplication

2011-11-01T11:39:24Z

Ticket 1 has been modified: Primitive object information duplication
Edited By: Frederick Martian (fredmartian)
_milestone updated: '' => u'Next Release (example)'
Description updated:
--- description-old

+++ description-new

@@ -1 +1 @@

-There seems to be quite a bit of duplication between the information in libomv.primitives.Primitive and libomv.assets.AssetPrim.PrimObject. We should try to combine these informaitions in one place if possible.
+There seems to be quite a bit of duplication between the information in libomv.primitives.Primitive and libomv.assets.AssetPrim.PrimObject. We should try to combine these informations in one place if possible.

Primitive object information duplication

2011-11-01T11:39:24Z

There seems to be quite a bit of duplication between the information in libomv.primitives.Primitive and libomv.assets.AssetPrim.PrimObject. We should try to combine these informaitions in one place if possible.

Primitive object information duplication

2011-11-01T11:39:24Z

Ticket 1 has been modified: Primitive object information duplication
Edited By: Frederick Martian (fredmartian)
_milestone updated: u'Next Release (example)' => u'Dynamic Protocol Handling '