gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: strk
Subject: Re: [Gnash-dev] About AMF (still technical)
Date: Thu, 4 Sep 2008 21:43:49 +0200

On Thu, Sep 04, 2008 at 01:31:37PM -0600, Rob Savoye wrote:
> strk wrote:

> >Can you give here a complete list of Element types that do NOT match 
> >with as_value ones ?
> 
>   http://wiki.gnashdev.org/AMF. element.h lists them all too.

>From the wiki: 

    * 3.1 NUMBER (type byte: 0x00) 
    * 3.2 BOOLEAN (type byte: 0x01)
    * 3.3 STRING (type byte: 0x02)
    * 3.4 NULL_VALUE (type byte: 0x05)
    * 3.5 UNDEFINED (type byte: 0x06)
    * 3.6 OBJECT (type byte: 0x08)
    * 3.7 OBJECT_END (type byte: 0x09)
    * 3.8 STRICT_ARRAY (type byte: 0x0a)

None of the above lacks a match on as_value.
element.h has some more, but I'm not sure they
are used at all or if they are part of RTMP or AMF.

Surely for SharedObject and remoting everything
comes from as_value and goes to as_value so there can
be no missing type.
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 ?

> >I belive LocalConnection and RTMP are the only cases not considered
> >by the "element_is_not_needed_here" party.
> 
>   True remoting will require Element, as it'll be using RTMP as well,
> and sending//receiving complex objects. The remoting openstreetmap.org
> is very simple, just sending a few numbers back and forth, so it's not a
> good usage case.

RTMP is just a transport protocol isn't it ?
openstreetmap transfers AMF over HTTP.
more performant (?) services will transfer over RTMP, but why should AMF 
be any different ?

--strk;




reply via email to

[Prev in Thread] Current Thread [Next in Thread]