Re: [Gnash-dev] About AMF (still technical)

[Rob Savoye]

strk wrote:

> Surely for SharedObject and remoting everything
> comes from as_value and goes to as_value so there can
> be no missing type.

  Eventually everything has to be an as_value (or an as_object in an 
as_value) so the interpreter can use it. Element is designed to work for 
both encoding & decoding equally. It's the low-level representation of 
an AMF element as stored. It's always been the plan to use Element and 
as_value. One low level, one high level.

  For one thing, Element handles properties for AMF objects better. 
While one can return the as_object in an as_value, and extract it's 
properties, it's not very simple... Elements are used to move complex 
objects around for the entire libamf/libnet API. Saying you don't need 
Element is the same as saying we should drop libamf and libnet 
completely. (which we are not going to do, btw)

> Can you handle to show evidence of other unsupported
> types required to be handled from other channels ?
> Like, can you stuff something in an FLV metadata which
> is not convertible to as_value ?

  Well, anything can go under the OBJECT type.

> RTMP is just a transport protocol isn't it ?

  RTMP is a protocol that uses complex AMF objects for all the packets. 
For instance, the initial connection packet is a NetConnection object 
that invokes a remote method to be executed, in this case,
NetConnection::connect(). Then it uses a NetStream object, and invokes 
NetStream::createStream(). Then it invokes NetStream::play(). All of 
these are complex AMF objects with many properties of any AMF type. 
Libnet both creates and parses these objects just fine now, to where 
they work with a real FMS 3 server.

> openstreetmap transfers AMF over HTTP.

  Right, a very simple usage.

        - rob -