[Top][All Lists]
[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;