views:

81

answers:

2

I'm evaluating PyAMF to replace our current PHP (ugh) AMF services framework, and I'm unable to find the one crucial piece of information that would allow me to provide a compelling use case for changing over:

Right now, new PHP AMF services are deployed simply by putting the .php files in the filesystem; the next time they're accessed, the new service is in play. Removal of a service is as simple as deleting the .php file that provided it, and updating it is correspondingly simple. I need that same ease-of-deployment from PyAMF. If we have to rewrite our installers to deploy these services, it'll be a nonstarter.

So, what I need to know is, can PyAMF support new service discovery by way of the filesystem, can it support service upgrading and removal by way of same, and if so, what is the best way to set it up to do this?

I'm open to any of the various server options; I can easily have cherrypy, django, whatever installed and running on its own, and even -- with a bit more sturm nd drang -- have mod_python or mod_wsgi made available.

A: 

I use PyAMF together with Django. A possible solution could roughly look like this:

  1. Create a python module containing all your different AMF services py files
  2. Create a view that wrapps the DjangoGateway and initialize all your services. Inside this view you could do the following:
    • reload() your service module
    • populate a dictionary based on i.e. the file names ({SERVICE_NAME: SERVICE_INSTANCE})
    • Instantiate DjangoGateway with this dictionary and let it handle the incoming request.

This is a hackish solution based on the fact that you can only deploy files without any additional actions like restarting a server.

aeby
Thank you for the initial suggestion. I'll admit, I'm looking for a non-hacky solution, if I can find one. I'll keep this in mind, though. I don't suppose you have a full example or a link to a tutorial that walks through this approach?
Chris R
No, sorry I have not. But the easiest method would be a lighttpd with fastcgi. Then you put your new fcgi python files in the server root.
aeby
+1  A: 

web2py includes pyamf support. The way it works is that you create functions like

def add(a,b): return a+b

and then you decorate them with @service.amfrpc3('domain')

@service.amfrpc3('domain')
def add(a,b): return a+b

You do not need to restart the web server or do anything else. You just add and delete functions in your controller file (the file where you define the services) and the service is made available or removed. You can also serve the same function using other protocols (xmlrpc, jsonrpc, rss, csv, xml, json) using multiple decorators.

@service.xmlrpc
@service.jsonrpc
@service.amfrpc3('domain')
def add(a,b): return a+b

You do not need to instantiate a Gateway (as with other frameworks. All decorated functions are exposed via a single action that you do not need to write because it is already in the scaffolding application (created by web2py for you):

def call(): return service()

The functions can access the web2py database abstraction layer (DAL) and (with some limitations) the web2py authentication mechanism.

You can edit the controller that contains the function using a shell (emacs/vi/etc) but you can also use the web2py web based IDE (called "admin") and add services using the browser.

Web2py includes a ticketing system therefore it is easy to debug web services. Any server side error results in a ticket. There is a web page in admin that lists all tickets. You click on one and it shows the code that caused the problem and the complete traceback.

You can import and use any third party python module. You must have pyamf pre-installed.

This is well documented in chapter 9 of the book:

http://web2py.com/book/default/section/9/2

web2py apps are very easy to deploy. One way is with point and click using admin. Another way is simply by copying files from one machine to another. There is no metadata, no installation procedure (not even for web2py itself), not settings, no configuration files. The latter process is somewhat described here:

http://gluonframework.wordpress.com/2010/03/02/shell-only-web2py/

web2py is based on WSGI. It run with any web server you can think of (apache+mod_wsgi/mod_python/mod_proxy;lighttpd/cheorkeey/ngnix+fcgi/wsgi.py;cherrypy;etc). Some options are documented in detail here:

http://www.web2py.com/book/default/section/11/0

Other options can be found on http://web2pyslices.com

web2py also comes with its own web server, Rocket, which supports https and is very fast. web2py code can also be deployed on Google App Engine.

Check for activity on the web2py google group.

mdipierro