[mtasc] RE: Open Source RTMP Development?

[Darwin Airola]

Ron,

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...

Take care,
Darwin


                            Darwin Airola
                      Chief Technology Officer
                    http://hypergalaxy.com/flash/
                       Darwin at HyperGalaxy.com
                            (847)839-9491

       HyperGalaxy(R): We develop solutions for the future.(TM)


-----Original Message-----
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.

Ron

Darwin Airola wrote:

>------------------------------
>
>Message: 6
>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
of
>
>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>
>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
free
>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
be
>nice to enhance some of Macromedia's existing functionality (we have found
a
>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
serialization/deserialization)?
>
>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
based"
>
>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>
>Ron> How many open source standard client/server communication procols
exist
>Ron> now?
>Ron> Web Services
>Ron> HTTP GET/POST
>Ron> ???
>Ron>
>Ron> Can we make a list of all of them and start to document what they
offer
>
>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
RTMP
>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
of
>others).
>
>Ron> Sorry for all the questions and few answers.
>Ron>
>Ron> Ron
>
>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.)
>
>Take care,
>Darwin
>
>
>                            Darwin Airola
>                      Chief Technology Officer
>                    http://hypergalaxy.com/flash/
>                       Darwin at HyperGalaxy.com
>                            (847)839-9491
>
>       HyperGalaxy(R): We develop solutions for the future.(TM)
>
>--
>MTASC : no more coffee break while compiling
>
>
>  
>