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

[strk]

On Thu, Sep 04, 2008 at 01:45:41PM -0600, Rob Savoye wrote:
> strk wrote:
> 
> >About testcases: self-contained ones would be far superior then internal
> >ones. One example is the recent Matrix-related test.
> >We have NO self-contained testcase failing, still an internal case was
> >failing due to misinterpretation of the requirements (the Flash model).
> 
>   All of the libamf and libnet test cases are self contained 
> executables with few dependencies. This way they can test the classes in 
> isolation, traditional unit testing style.

By self-contained I mean SWF files that can be run with a flash player
and unambiguosly tell whether the SWF file is working as expected or not.

See: http://wiki.gnashdev.org/SelfContainedTestcases


> >In this reguard, about AMF the only self-contained tests we have are:
> >
> >     - actionscript.all/SharedObject.as (SOL)
> >     - misc-ming.all/NetStream-SquareTest.c (FLV)
> 
>   There is also testsuite/libamf.all and testsuite/libnet.all, which 
> contain over 150 tests. Where are readAMF0's test cases ?

There's none indeed, we'll need to add one, but if we work 
on self-contained ones, automatically whatever is used will be tested,
be it element-based or buffer-based. It'd be a detail.


> >A task I'd like to undertake is using the SharedObject.as to test
> >circular-references, which may prove on-the-road the appropriateness
> >of Element vs buffer based approaches.
> 
>   Yes, you are hung up on circular references, but as I've never seen a 
> reference AMF type in the wild (and I've dug around heavily on the net 
> for examples), so I'm not so worried about this now. Yes, you can wrote 
> a test case that'll break SharedObject, but why unless you plan to fix it ?

Most of the times producing a self-contained testcase for me is a tool
for reverse-engeneering. It helps giving you the bigger picture, helps 
with modeling the later implementation (xcheck is great for that).

>   If you are just sending numbers or simple data around, yes, you don't 
> need Element. But once you start dealing with real AS objects with 
> properties, etc... you will need something like Element.

Why ?

> >But it is also important to implement a framework for testing other
> >uses and to improve the existing ones (FLV for instance could contain
> >lots more meta tags for us to test).
> 
>   I have test cases for all my uses of AMF. The current code (see 
> flvdumper) supports any AMF object in a Meta tag, so I don't see the 
> point. You're welcome to add more test cases to test_flv if you want 
> more complex tests.

I'm not saying Element-based stuff is broken, just not necessarely
convenient to use (and most likely unable to deal with circular refs).

> >Testcases needing new frameworks:
> >
> >     - Remoting (needs a simple server running during make check)
> >     - RTMP (needs a simple server running during make check)
> 
>   Which is Cygnal, remember ?. I'll be getting back to Cygnal as soon 
> as rtmpget fully works. We'll be able to use it for testing as well.

That'd be a great step forward.

--strk;