[SabreAMF] SabreAMF and ByteArray

[Evert | Rooftop]

The attachment was probably removed by the mailman.. But based on your 
description I did manage to decode the data from your earlier email.

I added in SabreAMF_ByteArray and it should be working now (on 
subversion) I also fixed the string reference issue..

Thanks a lot for these fixes.. I'm gonna test this for a few days and 
put out a 0.5

Evert


<?php

require_once 'SabreAMF/InputStream.php';
require_once 'SabreAMF/AMF3/Deserializer.php';
require_once 'SabreAMF/OutputStream.php';
require_once 'SabreAMF/AMF3/Serializer.php';

$msg = file_get_contents('dumps/bytearray2');
$stream = new SabreAMF_InputStream($msg);
$deser = new SabreAMF_AMF3_Deserializer($stream);
$obj = $deser->readAMFData();

var_dump($obj);

$stream = new SabreAMF_OutputStream();
$ser = new SabreAMF_AMF3_Serializer($stream);
$ser->writeAMFData($obj);

$stream = new SabreAMF_InputStream($stream->getRawData());
$deser = new SabreAMF_AMF3_Deserializer($stream);
$obj = $deser->readAMFData();

var_dump($obj);

?>


Jim Mischel wrote:
> 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
>>>>>   
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>