[SabreAMF] SabreAMF and ByteArray

[Jim Mischel]

Actually, this isn't a complete Flash Remoting request, but it is a 
complete AMF object.  We've been doing what I call "Flash Remoting 
Lite," just passing small AMF objects rather than full Flash Remoting 
requests.  I can deserialize objects of that type with this code:

$msg = file_get_contents('testdump2.bin');
$stream = new SabreAMF_InputStream($msg);
$deser = new SabreAMF_AMF3_Deserializer($stream);
$obj = $deser->readAMFData();

'testdump.bin' is the binary request.  And of course my code above won't 
work with the object I sent because the code isn't handling ByteArray.

It's 6:00 pm here and time for me to knock off for the night.  If you 
can work with the dump as I sent it, then great.  Otherwise I'll have to 
hack up a full Flash Remoting testbed for it tomorrow.

Unless, that is, you have such a thing that you can send me.

Jim

Evert | Rooftop wrote:

> 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
>>>>   
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>