[SabreAMF] SabreAMF and ByteArray

[Evert | Rooftop]

Any chance you can give me the raw data? converting that hexdump back to 
binary data didnt go too well :S

Perhaps you can zip that one up? This doesn't seem like a complete request..

Evert

Jim Mischel wrote:
> Evert
>
> Thanks.  I should have thought of the class-wrapper.
>
> I've included sample ActionScript code that creates an object 
> containing a ByteArray, and the resulting AMF dump.
>
>        // Create the object
>        var id: int = 23;
>        var command: String = "test";
>        var bytes:ByteArray = new ByteArray();
>        bytes.writeUTFBytes("this is a test");
>
>        var testo: Object = {id:id, command:command, bytes:bytes, 
> xxx:"jim"};
>
> The resulting dump:
>
> 0000: 0A 0B 01 0F 63 6F 6D 6D - 61 6E 64 06 09 74 65 73   
> ....command..tes
> 0010: 74 05 69 64 04 17 07 78 - 78 78 06 07 6A 69 6D 0B   
> t.id...xxx..jim.
> 0020: 62 79 74 65 73 0C 1D 74 - 68 69 73 20 69 73 20 61   
> bytes..this.is.a
> 0030: 20 74 65 73 74 01       -                           
> .test...........
>
> If you're going to get to this quickly, I'll hold off on coding it up 
> myself.
>
> Jim
>
> Evert | Rooftop wrote:
>
>> The best way to do something like this is a class-wrapper, because I 
>> think 'magic' behaviour is a really bad thing..
>>
>> So.. this would be something like:
>>
>> $byteArray = new SabreAMF_ByteArray($data);
>>
>> If you can give me an AMF sample, I can probably implement this 
>> pretty quickly.
>>
>> Evert
>>
>> Jim Mischel wrote:
>>
>>> SabreAMF does not currently support AMF type 0x0C, which is a Flash 
>>> ByteArray.  Looking at a dump of the AMF created when I pass a 
>>> ByteArray, it appears that the ByteArray format is very similar to 
>>> the String format.  That is, 0x0C followed by an integer-data 
>>> length, followed by the bytes in the array.  As with Strings, the 
>>> low bit of the length determines whether it's a literal ByteArray or 
>>> a reference to a previous ByteArray.
>>>
>>> It would be simple enough to code up something that reads this data 
>>> type, but there's a problem:  there is no PHP data type that 
>>> corresponds to a ByteArray.  It appears that I can use a PHP string 
>>> to hold the bytes, but that becomes problematic on serialization.  
>>> If the serializer sees a string, how does it know whether output it 
>>> as a String (type 0x06) or a ByteArray (type 0x0C)?  Being something 
>>> of a PHP novice, I could be missing something.  But there doesn't 
>>> appear to be a distinct PHP data type that I can use for the ByteArray.
>>>
>>> The solution I stumbled on was to mangle the name of the ByteArray 
>>> when I read it.  For example, if I get a ByteArray field called 
>>> 'data', I mangle the name by adding (prepending or appending) 
>>> something to the field name.  'data', for example, would become 
>>> 'data_BA' (for ByteArray).  This, of course, requires that I either 
>>> mangle every field name by adding its type, or tell clients that 
>>> they can't use variables that end in '_BA' (or whatever the mangling 
>>> characters are).
>>>
>>> The other problem with this approach is ... mangled names.  And 
>>> mangled names are a serious pain to work with, as we discovered 
>>> years ago when working with the Hungarian notation so common in 
>>> old-style Windows programming.  lpszFileName, and all that rot.
>>>
>>> Any thoughts on this one?  Suggestions how to handle ByteArray?
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sabreamf mailing list
>>> sabreamf at osflash.org
>>> http://osflash.org/mailman/listinfo/sabreamf_osflash.org
>>>   
>>
>>
>>
>>
>
>