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

[strk]

On Thu, Sep 04, 2008 at 12:40:33PM -0600, Rob Savoye wrote:
> strk wrote:
> >On Thu, Sep 04, 2008 at 12:16:40PM -0400, Jason Woofenden wrote:
> 
> >>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.
> 
>   openstreetmap.org is a simple user of remoting. Video streaming via 
> RTMP, as well as things like video conferencing are much more complex. 
> What we want is a solution that supports all the cases, and not just the 
> limited usage openstreetmap.org uses. Please think of the bigger 
> picture, and not just the one use case in front of your face.
> 
>   RTMP uses complex AMF Objects heavily, not just simple arrays.

I don't know much about RTMP, but my original question was:
can RTMP be seen (like FLV) as an upper layer, transferring
(among other things, like video and audio) *also* AMF-encoded
data ?

>   Is this some kind of silly competition ?

Evolution itself is a kind of silly competition :)
It's not between people, just mind products.

>   Don't forget LocalConnection, and RTMP. Both also use AMF. If you 
> seriously intend to completely ignore libamf, then you'd better fix the 
> RTMP support, all the testcases, and the utilities to use readAMF0. 

We'll get there if needs be, but I don't feel any rush in doing so.
I guess we can keep both Element-based and buffer-based encoder/decoder
for AMF and decide on a case-to-case basis which to use when.

> Otherwise you'll never know if readAMF0 and SimpleBuffer are sufficient 
> to handle RTMP.

Right. I don't know if it's sufficient atm.

> If you don't intend to fix all of this existing 
> infrastructure, then I suggest not doing anything at all, and waiting 
> till I get around to doing it the right way.

We're getting out with 0.8.3 "fix the damn media design" release shortly,
so I needed to get "metadata" FLV support in it, or the new design would
look poorer then the old one.
In doing so, I found the buffer-based code *more useful* for that task,
so I picked that one.

I'm sure the Element model fits your RTMP work more, so I'm not suggesting
to drop it as a whole (unless proven conceptually bogus).
I just tried to seed the discussion a bit with the REFERENCE and GC issues
which *may* invalidate the model. It's up to you whether to consider that
or ignore it.

--strk;