Re: [Gnash-dev] About AMF

[Rob Savoye]

strk wrote:
> I've been thinking about AMF and wanted to share some of that.

  It's about time somebody else was thinking about AMF...Just as a 
note, there is a bunch of information about AMF up on our wiki.

> the version you find in FLV is a function call, what you use for remoting
> is a function call.
> A function call is a name, a set of args and a return. Mostly just
> a string plus as_value types. 

  It's often used for much more than that, but basically yes, AMF is 
for serializing ActionScript objects. So it's not always a function 
call, but an object. The strings you see are property names, followed by 
it's associated data. In the FLV files you're looking at, AMF is used in 
a simpler fashion than for anything else.

> Now, the question is: why would we want another pointer-based
> (heap-allocated) intermediate class between as_value and AMF itself ?
> This intermediate class is amf::Element.

  If you change this, you'll have to change about 15,000 lines of RTMP 
code to work differently. The idea is that Elements are best suited for 
holding low level AMF data, and usually get deleted when converted to a 
higher level form, like as_value. As_values are designed for how a swf 
interpreter needs them to work internally, while Element is designed to 
handle the decoding & encoding of AMF data, and how it needs to be 
handled by the various other file formats, or RTMP.

> But again, if we do raise Element at the level of as_value, isn't it
> a code duplication ?

  Yes, but we've gotten into code duplication anyway. :-( I think 
Element and as_value while having similar roles, have very different 
focuses. Please don't even consider changing this without serious study 
of how *everything than handles AMF* needs to work, and not just the 
limited example of an FLV file.

> One of the reasons for Element to exist (if I got it correctly)
> is that it supports more types then as_value.

  It's because it supports *different* types, not an enlarged set.

> In particular Video/Audio types.
> Do we need to consider them part of the AMF format at all ?
> Can it be instead that Video/Audio are RTMP packet types instead
> and AMF is another packet type ?

  Audio and Video are only RTMP and FLV packet types, not AMF ones.

> The analogy with FLV looks interesting. FLV is a stream of tags
> (or packets if you want). Each packet has a timestamp. Content
> of the packet may be: Video, Audio, Meta; Meta is AMF-encoded.

  Just looking at FLV files is too limited a use of AMF to make any big 
changes to how AMF works. Please don't reinvent the wheel here.

> So, my feeling is that:
>
>         - AMF is *only* for serializing ActionScript values
>         - RTMP can contain ActionScript calls encoded in AMF
>         - FLV can contain ActionScript calls encoded in AMF (an RTMP session 
> snapshot?)

  Also SharedObject .sol files and LocalConnection memory segments also 
use AMF. SOL, LC, FLV, and RTMP all have different headers.

        - rob -