[erlang-questions] Project: Adobe release AMF3 specification for Flash/Flex - Joe's SP1 #9

[G Bulmer]

Roberto

Thank you very much for your help. You have cleared up several  
questions which were bugging me.

So, in summary, for server-push to a 'vanilla' Flex client (i.e.  
staying within the 'normal' Flex runtime+libraries technology):
1. it would be reasonable to use RTMP+AMF to implement server-push.
2. AMF is only data serialisation (it is supported by the Flex runtime 
+libraries, so it is convenient, and has reasonable performance).
3. Only RTMP is supported by the Flex runtime+libraries for server-push.

G Bulmer

> On Dec 13, 2007 11:58 PM, G Bulmer <gbulmer@REDACTED> wrote:
>> Thank you for the suggestions Roberto. I should have been clearer; I
>> am more interested in server-push, than client-pull.
>>
>>> On Dec 13, 2007 7:42 PM, G Bulmer <gbulmer@REDACTED> wrote:
>>>> Adobe has released a spec for Action Message Format -- AMF3
>>>> http://download.macromedia.com/pub/labs/amf/amf3_spec_121207.pdf
>>>>
>>
>>>> There is some helpful documents already at http://osflash.org/
>>>> documentation too, but it's nice to have the definitive spec.
>>>>
>>>> Further, Adobe say they will be releasing BlazeDS, the Java source
>>>> of the server components early 2008:
>>>> http://labs.adobe.com/technologies/blazeds/
>>>> Hopefully, this will include a nice test suite.
>>>>
>>>> So, it is becoming much easier to achieve Joe's SP1 point 9
>>>>> 9 ++++ interface to flash using flex 2. Solve the GUI problem
>>>>> once and
>>>>> for all as follows
>>>>>
>>>>>       repeat after me: client = flash in the browser, server =
>>>>> erlang.
>>>>> Intermediate protocol = flash AMF
>>>>>
>>>
>>> I still don't agree, but let's not discuss this here again ...
>>>
>>>>
>>>>
>>>> It's not that I dislike HTTP/HTML. I agree with pretty much all of
>>>> the benefits, but you can build some lovely client user  
>>>> interfaces in
>>>> Flex/AIR e.g. http://about.buzzword.com/ and it appears to be  
>>>> quicker
>>>> to build and test (on a range of relevant platforms) than browser-
>>>> hosted JavaScript-based apps.
>>>>
>>>> I'd be *very* interested in an *Open Source* implementation of an
>>>> Erlang AMF server.
>>>
>>> There are actually at least two Erlang open source  
>>> implementations of
>>> AMF encoder / decoders:
>>>
>>> eswf:
>>> http://eswf.googlecode.com
>> I did look at this, but the page says "Currently, eswf implements a
>> small subset of Flash 8 SWF tags and ActionScript bytecode"
>> Which didn't sound like it had got very far.
>> Are you saying it is well along?
>
> I was only referring to the eswf AMF encoder/decoder, which I had the
> impression, it was in a good shape,  many months ago , when I was
> trying it out.
>
>>
>>> Flash RTMP streaming server (not working yet, but has AMF encoder/
>>> decoder):
>>> http://erlyvideo.googlecode.com
>> This is new to me. Thank you. My impression from http://osflash.org/
>> documentation was that RTMP supports server-push to work with Flash
>> AMF. Is that not the case?
>
> Yes, AMF over RTMP gives you server push, so that project above is the
> right place you have to wait for, to eventually get what you want
>
>>> both projects allow you easily (technically and license-wise) to
>>> extract the AMF encoder/decoder so you can put it into the Erlang  
>>> web
>>> server of your choice !
>> I want to *push* from the server to the client, so I assume a web
>> server isn't the right place to start (unless that is how server-push
>> works for AMF, which is not the impression I got, so you may be
>> telling me something critical that had passed me by).
>>
>>> If you look for a flash remoting protocol which just works out of  
>>> the
>>> box with yaws, and if it has not necessarily to be AMF/AMF3, then  
>>> you
>>> could use also yaws HaxeRemoting:
>>> http://yaws.hyber.org/haxe_intro.yaws
>> AFAIK, this is client-pull, not server-push. Is that correct?
>
> yes, that is client pull as well
>
>> G Bulmer
>>
>>
>
>
>
> -- 
> Roberto Saccon
> http://rsaccon.com