AmFast 0.3 adds support for PyAmf

[limscoder]

AmFast (http://code.google.com/p/amfast/) is Flash remoting package for Python.

AmFast version 0.3 adds PyAmf support. Use PyAmf to encode and decode messages instead of AmFast's default C-extension for a pure-Python implementation.

AmFast 0.3 Features
=================
 * Support for NetConnection and RemoteObject RPC.
 * Producer/Consumer messaging via HTTP polling.
 * Support for ChannelSets with multiple Channels to expose resources in different ways.
 * Built in Channels for CherryPy, Twisted Web, and straight-up WSGI.
 * Easily configurable authentication for NetConnection and RemoteObject.
 * PyAmfEndpoint to encode/decode messages with pure Python, with no C compiler dependencies.
 * Optional C-extensions for speedy AMF encoding/decoding.

[lists-144]

Hi Dave,

congratulations with your new release. What I personally don't understand is why you're duplicating all of this stuff in a new library? You contributed a lot of work for the SQLAlchemy adapter in PyAMF and at some point you decided to create your own AMF library that basically does exactly the same as PyAMF, which doesn't make sense to me, because shouldn't we try to avoid duplication of effort here? Anyway, would be interesting to know what the rest of the people on this list think of it, I might be a little biased.

Cheers,

Thijs

On 11 May 2009, at 18:00, limscoder wrote:

AmFast (http://code.google.com/p/amfast/) is Flash remoting package for
Python.

AmFast version 0.3 adds PyAmf support. Use PyAmf to encode and decode
messages instead of AmFast's default C-extension for a pure-Python
implementation.

AmFast 0.3 Features
=================
* Support for NetConnection and RemoteObject RPC.
* Producer/Consumer messaging via HTTP polling.
* Support for ChannelSets with multiple Channels to expose resources in
different ways.
* Built in Channels for CherryPy, Twisted Web, and straight-up WSGI.
* Easily configurable authentication for NetConnection and RemoteObject.
* PyAmfEndpoint to encode/decode messages with pure Python, with no C
compiler dependencies.
* Optional C-extensions for speedy AMF encoding/decoding.
--
View this message in context: http://www.nabble.com/AmFast-0.3-adds-support-for-PyAmf-tp23487096p23487096.html
Sent from the pyamf-users mailing list archive at Nabble.com.

_______________________________________________
PyAMF users mailing list - users@...
http://lists.pyamf.org/mailman/listinfo/users

_______________________________________________
PyAMF users mailing list - users@...
http://lists.pyamf.org/mailman/listinfo/users

[Mike Dickson-3]

I had the same reaction.  Don't really understand what's
better/different from PyAMF itself....

Mike

On Mon, 2009-05-11 at 18:03 +0000, Thijs Triemstra | Collab wrote:

> Hi Dave,
>
>
> congratulations with your new release. What I personally don't
> understand is why you're duplicating all of this stuff in a new
> library? You contributed a lot of work for the SQLAlchemy adapter in
> PyAMF and at some point you decided to create your own AMF library
> that basically does exactly the same as PyAMF, which doesn't make
> sense to me, because shouldn't we try to avoid duplication of effort
> here? Anyway, would be interesting to know what the rest of the people
> on this list think of it, I might be a little biased.
>
>
> Cheers,
>
>
> Thijs
>
> On 11 May 2009, at 18:00, limscoder wrote:
>
> >
> > AmFast (http://code.google.com/p/amfast/) is Flash remoting package
> > for
> > Python.
> >
> > AmFast version 0.3 adds PyAmf support. Use PyAmf to encode and
> > decode
> > messages instead of AmFast's default C-extension for a pure-Python
> > implementation.
> >
> > AmFast 0.3 Features
> > =================
> > * Support for NetConnection and RemoteObject RPC.
> > * Producer/Consumer messaging via HTTP polling.
> > * Support for ChannelSets with multiple Channels to expose resources
> > in
> > different ways.
> > * Built in Channels for CherryPy, Twisted Web, and straight-up WSGI.
> > * Easily configurable authentication for NetConnection and
> > RemoteObject.
> > * PyAmfEndpoint to encode/decode messages with pure Python, with no
> > C
> > compiler dependencies.
> > * Optional C-extensions for speedy AMF encoding/decoding.
> > --
> > View this message in context:
> > http://www.nabble.com/AmFast-0.3-adds-support-for-PyAmf-tp23487096p23487096.html
> > Sent from the pyamf-users mailing list archive at Nabble.com.
> >
> > _______________________________________________
> > PyAMF users mailing list - users@...
> > http://lists.pyamf.org/mailman/listinfo/users
> >
>
>

_______________________________________________
PyAMF users mailing list - users@...
http://lists.pyamf.org/mailman/listinfo/users

[Nick Joyce]

Congratulations to Dave on the release - looking at the commit logs, a  
lot of work has gone into it!

I would tend to agree with Thijs; although obviously being one of the  
core contributors to PyAMF I am also probably biased ;)

AmFast pins itself as "a Flash remoting framework for Python" whereas  
PyAMF is meant to be a library that people can build on top of. It  
does appear that a lot what is already accomplished in PyAMF is  
duplicated in AmFast.

This includes the core en/decoders, class mapping, remoting (including  
basic RemoteObject support) etc. This is all that PyAMF provides (and  
is intended to provide). AmFast also includes RemoteObject  
authentication, Producer/Consumer messaging, channels and an as3 VO  
code generator (Dave please jump in and correct me here).

I can understand the need to speed up the en/decode time for PyAMF but  
we have not prematurely optimised the code, rather focussing on a  
good api, unit tests and excellent integration with other frameworks  
such as Django, GAE, Twisted, SQLAlchemy (the latter Dave contributed  
- thanks for that!). I would like to point out that this has been  
(mostly) achieved with 0.4.2.

Since that release, we have been working on profiling and refactoring  
the code and have achieved some quick (and substantial) wins, both  
with the pure python and c extension. The C extension has pretty much  
had a rewrite and I am starting to move more and more core  
functionality into C-space.

It would probably be good to point out that in 0.4.2, only one Python  
class was rewritten in C (pyamf.util.BufferedByteStream), not the  
reference checking or the en/decoders so its no wonder that AmFast is  
getting the speedups it does (and I haven't verified the claims, yet).

This new code will eventually end up in PyAMF 0.5 however getting  
RTMPy 0.1 out the door is our main focus so this may be a couple of  
weeks away..

What I would like to see here some sort of collaboration between the  
two projects and perhaps attempt to merge the two works into one  
project - to remove the duplication of work?

As a sidenote, I would also like to say that announcing a new release  
on a 'competing' projects' mailing list could be considered bad form -  
would linux be happy if freebsd announced a new release on one of  
their main lists?

Nick

On 11 May 2009, at 19:36, Mike Dickson wrote:

> I had the same reaction.  Don't really understand what's
> better/different from PyAMF itself....
>
> Mike
>
> On Mon, 2009-05-11 at 18:03 +0000, Thijs Triemstra | Collab wrote:
>> Hi Dave,
>>
>>
>> congratulations with your new release. What I personally don't
>> understand is why you're duplicating all of this stuff in a new
>> library? You contributed a lot of work for the SQLAlchemy adapter in
>> PyAMF and at some point you decided to create your own AMF library
>> that basically does exactly the same as PyAMF, which doesn't make
>> sense to me, because shouldn't we try to avoid duplication of effort
>> here? Anyway, would be interesting to know what the rest of the  
>> people
>> on this list think of it, I might be a little biased.
>>
>>
>> Cheers,
>>
>>
>> Thijs
>>
>> On 11 May 2009, at 18:00, limscoder wrote:
>>
>>>
>>> AmFast (http://code.google.com/p/amfast/) is Flash remoting package
>>> for
>>> Python.
>>>
>>> AmFast version 0.3 adds PyAmf support. Use PyAmf to encode and
>>> decode
>>> messages instead of AmFast's default C-extension for a pure-Python
>>> implementation.
>>>
>>> AmFast 0.3 Features
>>> =================
>>> * Support for NetConnection and RemoteObject RPC.
>>> * Producer/Consumer messaging via HTTP polling.
>>> * Support for ChannelSets with multiple Channels to expose resources
>>> in
>>> different ways.
>>> * Built in Channels for CherryPy, Twisted Web, and straight-up WSGI.
>>> * Easily configurable authentication for NetConnection and
>>> RemoteObject.
>>> * PyAmfEndpoint to encode/decode messages with pure Python, with no
>>> C
>>> compiler dependencies.
>>> * Optional C-extensions for speedy AMF encoding/decoding.
>>> --
>>> View this message in context:
>>> http://www.nabble.com/AmFast-0.3-adds-support-for-PyAmf-tp23487096p23487096.html
>>> Sent from the pyamf-users mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> PyAMF users mailing list - users@...
>>> http://lists.pyamf.org/mailman/listinfo/users
>>>
>>
>>
>
> _______________________________________________
> PyAMF users mailing list - users@...
> http://lists.pyamf.org/mailman/listinfo/users

_______________________________________________
PyAMF users mailing list - users@...
http://lists.pyamf.org/mailman/listinfo/users

[limscoder]

My motivation for writing AmFast started with wanting better encode/decode performance for large object graphs. My initial plan was just to create a C-extension that would plug-in to PyAmf's remoting library. As I was working on the C-extension, I started thinking about how I could implement features like Producer/Consumer messaging, Channels, etc... I came to the conclusion that it would take major changes to PyAmf's core architecture to implement these features, and that it would be easier to start something new.

I definitely think we can work together to make something better. AmFast is built to work with different Channels and Endpoints. I think this is where we can collaborate. We can work together to build a unified messaging framework that can accept, process, and send messages. The messaging framework would use message objects as input/output, and would be completely unaware of how the messages are received/sent and encoded/decoded. This core code would be re-useable with PyAmf, AmFast, RTMPy, SOAP, or anything else.

Nick, sorry if I overstepped by announcing AmFast here. I wouldn't have posted it, other than I wanted to highlight the new version's ability to use PyAmf as the encoder/decoder.

[Arnar Birgisson]

On Mon, May 11, 2009 at 22:22, limscoder <dthomp325@...> wrote:
> Nick, sorry if I overstepped by announcing AmFast here. I wouldn't have
> posted it, other than I wanted to highlight the new version's ability to use
> PyAmf as the encoder/decoder.

I don't think there is any harm done, and it is always good for
"competing" project to know about each other. We are all playing for
the same team.

It seems to me that what you really want is an object messaging
middleware. This is fine of course, and having PyAMF as a potential
backend sounds great. You should compare with the numerous other
messaging middlewares though.

However, I must say that IMHO this is one case where over-design can
come back to bite you. Decoupling messaging APIs from the underlying
transport library generally results in the lowest common denominator
being applied, setting severe constraints on the APIs and
under-utilizing the actual protocols. For this reason I quite like how
PyAMF bases a set of _light-weight_ messaging APIs on top of its core
functionality (AMF serialization). In my experience, such utilities
are more useful and flexible, outweighing the benefits of a
multi-backend messaging middlewares. The fact is that most of the time
people end up using just one transport anyways (take the horror that
is SOAP for an example).

The true benefit of AMF comes from that it is native for the Flash
Player. I'm not sure it is a better fit as a general purpose
serialization format than, say, JSON or Google Protocol Buffers. Thus,
I think that the most valuable focus for the PyAMF team is to focus on
performance improvements for AMF and getting the RTMP implementation
into shape as that gives you a *very* good messaging solution where
one or both of the endpoints are running on the Flash platform. After
all, implementing RTMP was the initial motivation for starting PyAMF
:)

Just my 2 cents.

cheers,
Arnar
_______________________________________________
PyAMF users mailing list - users@...
http://lists.pyamf.org/mailman/listinfo/users

[limscoder]

Arnar Birgisson wrote:

It seems to me that what you really want is an object messaging
middleware. This is fine of course, and having PyAMF as a potential
backend sounds great. You should compare with the numerous other
messaging middlewares though.

Thanks for your input. I agree that we don't need to completely abstract the messaging API, but I would like to see something that is abstracted enough that you can connect to the same resources using AMF over http, long-polling, streaming http, or RTMP.

That's what I had in mind when I started the remoting portion of AmFast. The configurable Channels and Endpoints let you choose how to send/receive and encode/decode messages, but it is still heavily tied to the idea of an AMF 'packet' and the FlexMessaging format. You can expose the Packet and Message objects to a Target's callable, so that you can read and write Packet and Message headers directly. I would not want to abstract to the point of hiding headers, or information like a Flex Message's clientId.

This architecture makes it easy to add new ways to expose resources. For example, it should be relatively easy to create an RTMP Channel for AmFast once the RTMPy project is further along. Then you'll be able to serve RTMP connections to clients that support it, while serving the same resources and messages over http connections for other clients.

[lists-144]

On 12 May 2009, at 00:00, Arnar Birgisson wrote:

> Thus,
> I think that the most valuable focus for the PyAMF team is to focus on
> performance improvements for AMF and getting the RTMP implementation
> into shape as that gives you a *very* good messaging solution where
> one or both of the endpoints are running on the Flash platform. After
> all, implementing RTMP was the initial motivation for starting PyAMF
> :)

Hell yeah, getting really close now, for those interested check http://rtmpy.org

Cheers,

Thijs


_______________________________________________
PyAMF users mailing list - users@...
http://lists.pyamf.org/mailman/listinfo/users