[Gnash-dev] Re: About AMF

[Jason Woofenden]

>strk said:
>>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.
>
rob said:
>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.

OK, this just isn't true. This is one of my beefs with Element. AMF is not
always an object. In fact in my experience with NetConnection.call() it never
is. strk is correct in saying that there's a function name in the headers, then
a value encoded with amf. That's the way it is with NC.call anyway

Element class seems to be centered around the idea the idea of a set of
"properties" (ie key/value pairs) which are only present in the "Object" AMF
type, and not in any of the other types.

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.


Seems to me the common ground with all the uses of AMF (used in RTMP,
NetConnection.call(), flv files, .sol files... etc) is that they all serialize
an as_value in the same way. These different uses seem to have different
headers, eg I looked at the .sol file format, and it has totally different
headers before the AMF data.

This is why I wrote a nice function for converting AMF encoded value to/from
as_value.


rob said:
>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.

rob: I think you know full well that strk has been considerably involved in the
remoting code for NetConnection.call(). he even mentioned it in the e-mail
you're replying to here. Please stop being insulting and consider the fact that
maybe you're not doing this the best possible way. I've been trying for months
to engage you in a meaningful dialog about why you've designed Element the way
you have, and for that matter why you have it at all.

This is a group project. Other members of the group think that you may be
making bad design decisions. You need to justify/explain the choices you've
made. If you keep dodging all investigation with crap like "you haven't looked
at much of the code" and "there's 1500 lines of code" etc, then we're just
going to have to work around you, and will probably end up having to replace
most of your work with something functional.

I've looked at a considerable amount of the existing code for handling AMF and
just about everything I've seen has been badly designed, inneficient,
innacurately commented and buggy. It's my opinion that it would be easier to
re-write this stuff that to fix it.

If you want to convince this developer community that we should use your code,
and that we should maintain it in the case of your absense, you need to explain
to us your reasons for designing it that way, not just dodge the question by
telling us that we don't know much about it. If there's something you think we
don't know: tell us.

Take care,

       - Jason