[mtasc] RE: Open Source RTMP Development?
darwin at hypergalaxy.com
Fri Apr 29 22:19:53 CEST 2005
You might be correct.
It is actually probably a "some of this and less of that" argument, as it is
very nice to use Flash's client infrastructure (thus, the emergence of
AMFPHP, for example). However, I guess that FlashComm is more of a niche
than Flash Remoting...
Chief Technology Officer
Darwin at HyperGalaxy.com
HyperGalaxy(R): We develop solutions for the future.(TM)
From: Ron Wheeler [mailto:rwheeler at artifact-software.com]
Sent: Friday, April 29, 2005 1:39 PM
To: darwin at hypergalaxy.com; MotionTwin ActionScript2 Compiler List
Subject: Re: [mtasc] RE: Open Source RTMP Development?
I am still not convinced that it would not be easier to develop the
client than to try to chase Macromedia's development through reverse
engineering. Everytime they added or changed functionality, you would
have to redo the whole reverse engineering process to be sure that you
still were compatible.
Darwin Airola wrote:
>Date: Fri, 29 Apr 2005 11:17:49 -0400
>From: Ron Wheeler <rwheeler at artifact-software.com>
>Subject: Re: [mtasc] RE: Open Source RTMP Development?
>To: MotionTwin ActionScript2 Compiler List
> <mtasc at lists.motion-twin.com>
>Message-ID: <4272501D.4070702 at artifact-software.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Ron> If you are going to write the server side, why not just build a client
>Ron> side as well. There does not seem, on the surface at least, too much
>Ron> an advantage gained by worrying about building a server that is
>Ron> compliant with a client that is compliant with a server that you are
>Ron> not going to use anyway.
>Ron> The client side can not be that big and if you pick something that
>Ron> follows a reasonably popular standard, you can likely get the heart of
>Ron> both sides.
>Actually, I only need the server side, as Flash provides a free client.
>My main impetus for wanting to do this is to be able to offer a license
>option to clients (and potential clients) who cannot afford or do not want
>to pay Macromedia's expensive server licensing fees. After that, it would
>nice to enhance some of Macromedia's existing functionality (we have found
>number of bugs in Macromedia's server, for example) and add new
>functionality that Macromedia should have added but did not.
>Ron> How big a performance improvement do you want to get over the standard
>Ron> client/server protocols that are currently available? Where is it
>Ron> likely to come from(compression, faster
>Actually, we are fine with Flash Communication Server's performance, as is.
>We would like an open source option for the aforementioned reasons.
>Ron> This is a problem that we all face and an open source "standards
>Ron> solution that handles the types of assets that RIA programmers need to
>Ron> transfer would be adopted pretty quickly if it were done well.
>Ron> How many open source standard client/server communication procols
>Ron> Web Services
>Ron> HTTP GET/POST
>Ron> Can we make a list of all of them and start to document what they
>Ron> and what the do not offer that is relevant to our needs?
>Ron> It may be possible to build a layered or plug-in style protocol that
>Ron> gives some flexibility to the choice of what you get delivered at each
>Ron> end. (Objects==Objects,query== simple assets, Data==Database,
>Ron> query==data, ) or maybe not if the performance penalty is too high.
>That is sort of how a lot of protocols work, now.
>Our issue is, again, that we would like to offer clients a license from
>server. The main reason for wanting to go with RTMP is because we can then
>leverage our library of existing RTMP client components (as well as those
>Ron> Sorry for all the questions and few answers.
>In any case, it, unfortunately, looks like no one is work on an open source
>RTMP implementation and no specification is available. A specification
>could, of course, be reverse engineered, but that would take time that most
>people do not have... (On top of that, there might be codec licensing
>issues, but, depending upon the codec that is used, we might have a royalty
>free version of our own.)
> Darwin Airola
> Chief Technology Officer
> Darwin at HyperGalaxy.com
> HyperGalaxy(R): We develop solutions for the future.(TM)
>MTASC : no more coffee break while compiling
More information about the mtasc