TomByrne / tuio-as3

Automatically exported from code.google.com/p/tuio-as3
0 stars 0 forks source link

org.tuio.osc.OSCBundle calls OSCMessage.bytes instead of OSCMessage.getBytes #8

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
OSCMessage lazily writes its bytes as getBytes is called.  OSCBundle tries to 
write the bytes as new data is written to the bundle.  As a result, it writes a 
message's empty ByteArray instead of calling message.getBytes() and writing the 
packet's composed bytes.

Original issue reported on code.google.com by bsimpson on 6 Aug 2010 at 12:17

GoogleCodeExporter commented 9 years ago
I've reworked OSCBundle to lazily create a ByteArray when getBytes is called, 
just like OSCMessage does.  

I feel like this whole package could be cleaned up a bunch, including:
 - resolving the difference between this.bytes and getBytes();
 - making the functions side-effect free 
        (There's a lot of implicit magic in the OSCPacket class which makes, but does not assert, assumptions about bytes.position.); 
 - deciding whether we to use public vars or protected var with getters/setters for the interface; and
 - using those variables instead of getters for class implementation.

Original comment by bsimpson on 6 Aug 2010 at 2:26

Attachments:

GoogleCodeExporter commented 9 years ago
Note: This patch works for me, but has not yet been tested extensively.

It introduces a default timetag for OSCBundles that have not explicitly been 
timestamped.  The timetag should default to the time getBytes() is called.  I'm 
using the SECONDS_1900_1970 constant plus epoch time now, but I'm not sure if 
the value it is calculating is accurate.  If absolute time matter in your 
application, double-check that value.

Original comment by bsimpson on 6 Aug 2010 at 2:30

GoogleCodeExporter commented 9 years ago

Original comment by gimmix...@gmail.com on 14 Sep 2010 at 5:40

GoogleCodeExporter commented 9 years ago
I added a getBytes function but it is not as lazy as the proposed function -> 
more like the OSCMessage's getBytes.

The internal bytes is currently handled like that mainly due to performance 
reasons when parsing a received ByteArray. In a very early release the 
ByteArray was copied so that every Object has it's own ByteArray containing 
it's section of the original ByteArray but that was quite expensive.

Original comment by gimmix...@gmail.com on 14 Sep 2010 at 6:30

GoogleCodeExporter commented 9 years ago

Original comment by gimmix...@gmail.com on 17 Sep 2011 at 3:21