|
»
»
« Return to Thread: AmFast 0.3 adds support for PyAmf
Re: AmFast 0.3 adds support for PyAmf
by Nick Joyce
::
Rate this Message:
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
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
« Return to Thread: AmFast 0.3 adds support for PyAmf
| Free embeddable forum powered by Nabble | Forum Help |
