News about my FOSS projects

Thursday, April 15, 2010

On adding AMF (RPC) support for Trac

SAN JOSE, CA - JANUARY 15: The Adobe logo is ...Image by Getty Images via Daylife Try experimental features in Trac XmlRpcPlugin

Another important milestone. Few months after Odd Simon Simonsen invited me to help in developing the very successful and useful plugin TracXmlRpc plugin, and few days after implementing Hessian support for Trac, it's time to focus on Action Message Format. Yes ! Things move fast because it's so easy.

Action Message Format is a binary protocol designed by Macromedia, actually part of Adobe Systems. It's goal is to serialize and deserialize ActionScript objects in order to exchange data between an Adobe Flash application (e.g. Adobe Flash Player ) and a remote service, usually over the internet. In other words it allows using Flash Remoting MX together with ActionScript so as to develop interactive applications , in this particular, by retrieving the data managed by any Trac environment. Few minutes ago I finally could invoke remote services via this protocol using a Python script. The details ...

Subscribe using RSS

... I don't want to reveal all the details since the implementation of the underlying API is not completely stable or ready to be released and probably not a few details will change in a near future. However this example helped to figure out how some method should exchange information needed to process the RPC request.

Well, the whole story starts with an enhancement request and a patch submitted to plugin TracXmlRpc issue tracker by thijs . At that moment the only protocols supported were XML-RPC, JSON-RPC. The former was fully supported by standard xmlrpclib.ServerProxy, whereas the later could be used by installing libraries like wsgi-jsonrpc. On the other side there was no way to add further protocols by installing third-party plugins. In a near future this will be possible. The component I am talking about is consistent with that approach. In this particular case, thijs also provided an example based on PyAMF library. I just needed to tweak it a little in order to get this script :

#!/usr/bin/env python

AMF client for the Trac RPC plugin.

import base64
from optparse import OptionParser
from socket import error
import sys

from pyamf.remoting import RemotingError
from pyamf.remoting.client import RemotingService

p = OptionParser()

p.add_option("-U", dest="username",
                help="Trac USER", metavar="USER")
p.add_option("-P", dest="password", metavar="PASSWORD",
                help="use PASSWORD to authenticate USER")
p.add_option("-e", dest="env", metavar="URL",
                help="base URL of target environment")

(opts, args) = p.parse_args()

username = opts.username
password = opts.password
try :
url = opts.env + '/rpc'
except :
sys.exit("Missing Trac environment. Use -e option.")

service_name = 'system'

gw = RemotingService(url)
if (username, password) != (None, None):
auth = base64.encodestring('%s:%s' % (username, password))[:-1]
gw.addHTTPHeader("Authorization", "Basic %s" % auth)

service = gw.getService(service_name)

  print service.getAPIVersion()
except RemotingError, e:
  print e
except error, e:
  print e[1]

This script shows the installed version of the plugin . As you can see if the base URL of the Trac environment is at e.g. http://localhost/trac then the protocol is available at http://localhost/trac/rpc. In fact this URL can be used to access all (well, most of ;o) the active protocols installed in a given environment. Protocol selection at that path is based on Content-Type header supplied by the client in the HTTP request (e.g. application/x-amf for AMF). That's the main requisite considered by Odd in order to design the underlying API , and it's great !!! .

In order to see it action, you just need to open a console and type

$ python ./ -U username -P mypassword -e http://localhost/trac
[1, 1, 0]

That's it! . Below you can see a simplified version using just the Python interpreter.

>>> import base64
>>> from pyamf.remoting import RemotingError
>>> from pyamf.remoting.client import RemotingService
>>> username, password = 'olemis', 'mypassword'
>>> url = 'http://localhost/trac/rpc'
>>> gw = RemotingService(url)
>>> auth = base64.encodestring('%s:%s' % (username, password))[:-1]
>>> gw.addHTTPHeader("Authorization", "Basic %s" % auth)
>>> service = gw.getService('system')
>>> print service.getAPIVersion()
[1, 1, 0]

Isn't it simple ? All these implementations will be offered soon by TracRpcProtocols. The underlying API needs to be released before that, of course ;o). If you'd like to follow the development of this features then I invite you to subscribe to the RSS feed. Adding AMF support for Trac is just the second episode of the first season. Thanks osimons and thijs ;o) .

Reblog this post [with Zemanta]

Friday, March 5, 2010

On adding Hessian (RPC) support for Trac

Duke, the Java Mascot, in the waving pose. Duk...Image via Wikipedia Multi-protocol Trac RPC API

Yesterday was a historical date. In the morning I finally could request the data managed by a Trac instance via Hessian RPC. The whole story ? Well ... Few months ago Odd Simon Simonsen invited me to participate and send patches to the very popular and successful XmlRpcPlugin. In order to do that he cloned the SVN repository using Hgsvn, published its contents at Bitbucket and created an MQ repository. We are developing new patches in there. Right now we are both working on an API to support RPC calls via multiple protocols (beyond built-in XML-RPC and JSON-RPC implementations ;o). We needed a protocol to experiment with and tune up the current prototype. Hessian was the target for this research.

Subscribe using RSS

Hessian is a binary, dynamic, and very efficient RPC protocol. It's very popular in Java. Nonetheless (unlike others like RMI ...) it can be implemented on top of any language, and that includes Python as well. It's dynamic nature (similar to XML-RPC) helps with the bindings.

So far I'd not like to unveil the implementation details and the impact this might have on the underlying API (because changes will be applied soon ;o), but I'd like to show how to request data to Trac using this protocol. It's very simple !

>>> from hessian.client import HessianProxy as HSP
>>> auth = {'username' : 'olemis', 'password' : 'canhurtyoureyes'}
>>> hsp = HSP('http://localhost/trac/newprj/hessian', auth)
>>> getattr(hsp, 'system.getAPIVersion')()
[1, 1, 0]

That's it ! If you'd like to follow the development of this features then I invite you to subscribe to the RSS feed. Adding Hessian support for Trac is just the beginning to raise a wonderful plugins ecosystem ;o) . You should be able to access your data the way you want !

Reblog this post [with Zemanta]

Thursday, January 21, 2010

TracGViz plugin downloaded more than 1000 times (> 300 from PyPI)

TracGViz plugin

Among the Trac plugins I've implemented so far TracGViz has an special place. Recently, this module has surpassed the 300 downloads from PyPI. This is only a fraction of the total because it is possible to download it from Softpedia (518 downloads for Mac and 203 downloads for Linux) and from WareSeeker (12 downloads). In total 1055 downloads have been made, considering the 322 from PyPI. But who knows, maybe there are other sites that offer similar services. However these numbers (note that I am only speaking of version 1.3.4 ;o) are enough to fulfill my expectations. For more details, please read this short entry and consult the  documentation in the project site.

This plugin integrates the PMS with the technology known as Google Visualization API to enhance the Trac wiki with mini-applications of all kinds. It also allows to display and process data managed by a project environment, but on sites located beyond the domain where the management system is located. As a side effect it extends the Trac RPC API providing access (create, read, execute) to the reports, to data about the source code and its versions, and details of the events recorded during the lifetime of the project.

This is one of the huge welcoming signs for Go...Image via Wikipedia

Currently (i.e. up to version 1.3.4) an optimistic estimate indicates that this tool can satisfy only about 10% percent of the use cases for this Google technology. However, version 1.4.1 will be ready soon and it will cover about an 80% percent, and especially some of the most common tasks. The improvements provide new features for users, support to display multiple views of the same data using any of the available widgets as well as integration with other systems. Several tests show that its operation is stable.

A practical example will be posted soon on this blog. So my advice is to follow the new blog articles. I hope they will be useful for you.

Reblog this post [with Zemanta]