Russ Nelson wrote:
Perhaps they can be running on gnashdev? If you're offline and can't
get to gnashdev, then treat them as "untested".
Since Cygnal is part of Gnash, everyone will have a local server to
test against,. :-) But yes, we can also install a "known working" server
on gnashdev
strk writes:
> Testcases needing new frameworks:
>
> - Remoting (needs a simple server running during make check)
> - RTMP (needs a simple server running during make check)
Perhaps they can be running on gnashdev? If you're offline and can't
get to gnashdev, then treat them as "unt
> While you say I'm ignoring your technical issue, I see you totally ignoring
> the bigger picture of what RTMP needs to work, and not being very open
> minded about those issues. Somewhere in the middle is probably a perfect
> solution. :-)
What's the bigger picture of what RTMP needs to work?
>> 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
strk wrote:
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 ?
Yes, RTMP transfers AMF encoded data, as well as audio and video. RTMP
also has a bunch of
strk wrote:
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.
Right, but I also really like unit level tests. Running all test code
in a full flash interpreter can create problems that aren't real
strk wrote:
Surely for SharedObject and remoting everything
comes from as_value and goes to as_value so there can
be no missing type.
Eventually everything has to be an as_value (or an as_object in an
as_value) so the interpreter can use it. Element is designed to work for
both encoding &
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 t
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
On Thu, Sep 04, 2008 at 09:32:17PM +0200, Benjamin Wolsey wrote:
>
> > Testcases needing more attention:
> >
> > - actionscript.all/LocalConnection.as
> > -> currently fails
> >
>
> Sorry to pollute the technical discussion with details, but this doesn't
> fail for me, and runs comple
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)
*
> Testcases needing more attention:
>
> - actionscript.all/LocalConnection.as
> -> currently fails
>
Sorry to pollute the technical discussion with details, but this doesn't
fail for me, and runs completely valgrind clean, so whatever's causing
it to fail for you doesn't seem stra
strk wrote:
I'm not planning to change any RTMP related code, still too ignorant
about it anyway.
Which is my point. But it sure seems a huge waste of time to implement
new code when there is *tested* code that already works. It also seems a
shame to implement a new code base that ignores m
On Thu, Sep 04, 2008 at 12:40:33PM -0600, Rob Savoye wrote:
> 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.
About testcases: self-contained ones would be far superior then internal
ones. On
Jason wrote:
> 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 abou
On Thu, Sep 04, 2008 at 07:42:08AM -0600, Rob Savoye wrote:
> strk wrote:
> >Now, the question is: why would we want another pointer-based
> >(heap-allocated) intermediate class between as_value and AMF itself ?
> >This intermediate class is amf::Element.
>
> If you change this, you'll have to
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
> >>ty
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. V
On Thu, Sep 04, 2008 at 12:16:40PM -0400, Jason Woofenden wrote:
> 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. I
On Wednesday 03 September 2008 16:38:56 strk wrote:
> On Wed, Sep 03, 2008 at 09:40:27AM -0700, Mark Voorhies wrote:
> > On Wednesday 03 September 2008 04:10:54 strk wrote:
> > > On Tue, Sep 02, 2008 at 11:23:01PM -0700, Mark Voorhies wrote:
> > >
> > > > I think that pushing the reflection into s
On Thu, Sep 4, 2008 at 12:31 PM, Rob Savoye <[EMAIL PROTECTED]> wrote:
> You obviously fail to grasp the
> multitude of ways AMF gets used, which makes any serious discussion
> impossible.
The ONLY REASON there's no serious discussion is that YOU REFUSE to
give serious answers.
I just made a quit
Jason Woofenden writes:
> 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.
AND it's spelt wrong!
> If you want to convince this developer community that we
Jason Woofenden wrote:
strk said:
Sorry, I'm not into a big flame war. You obviously fail to grasp the
multitude of ways AMF gets used, which makes any serious discussion
impossible.
We'll discuss this in much more detail at the hackathon.
- rob -
>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
>seria
strk wrote:
I've been thinking about AMF and wanted to share some of that.
It's about time somebody else was thinking about AMF...Just as a
note, there is a bunch of information about AMF up on our wiki.
the version you find in FLV is a function call, what you use for remoting
is a functi
I've been thinking about AMF and wanted to share some of that.
My impression is that AMF (which may stand for Another Marshalling Format)
is pretty much only needed to serialize function calls:
the version you find in FLV is a function call, what you use for remoting
is a function call.
A function
26 matches
Mail list logo
