Re: [Gnash-dev] Re: About AMF (Techical)

[strk]

On Thu, Sep 04, 2008 at 12:16:40PM -0400, Jason Woofenden wrote:

> Element class seems to be centered around the idea the idea of a set of
> "properties" (ie key/value pairs) which are only present in the "Object" AMF
> type, and not in any of the other types.
> 
> This is not the standard type. In fact in all my experience with
> NetConnection.call connecting to the openstreetmap.org server, the Object type
> is not used at all.

I figured. Indeed I had to add decoding support for one kind of object
(the ECMA_ARRAY thing) for FLV.

> Seems to me the common ground with all the uses of AMF (used in RTMP,
> NetConnection.call(), flv files, .sol files... etc) is that they all serialize
> an as_value in the same way. These different uses seem to have different
> headers, eg I looked at the .sol file format, and it has totally different
> headers before the AMF data.
> 
> This is why I wrote a nice function for converting AMF encoded value to/from
> as_value.

The AMF to as_value is now exposed in the as_value class, the other one still
isn't. I'm sure there are another 3/4 passes required to clean it up, in 
particular
for AMF version and references (the latter should be easy to test).

As for a status report, the users of as_value::readAMF0 so far are:
        - NetConnection (remoting)
        - FLVParser (libmedia for NetStream)
Candidate other users:
        - SharedObject
Needed to complete the round-trip:
        - as_value::to_AMF(&stream) or something like that
          (taking a SimpleBuffer or a stream, so the function can
           easily 'append' to the output channel and the caller can
           control offset at which to start writing to it).

--strk;