Even if you still don't know, it is a fact that I'm a convinced Python advocate and developer. I like programming and I also think that Trac is one of the most well-designed systems out there. I have implemented some plugins myself (hope you like them ;). Besides it's pretty famous and there are countless online installations . Nonetheless in the last few years its development was not as fast as many of us would have wanted . There are some reasons for this to happen . Firstly Edgewall (the company behind Trac) is not what it used to be once upon a time. Besides the site hosting many plugins needs an upgrade since long time ago . In my opinion it'd be nice to migrate the VCS so as to use a distributed system , let's say either Mercurial or Git (I vote for the former ;) . According to my personal experience it also happens that plugin developers might not have enough support to dedicate time to make their ideas a reality, and decide to take another job. Recently I got some good news . There's strong interest to support its development . The whole thing started few months ago when a message was sent to trac-users and trac-dev mailing lists. Now, thanks to Wandisco, this request led to a proposal named Bloodhound willing to support its development, but incubated under the Apache (ASF) umbrella. So far the idea is to create a friendly fork of the core Trac distribution and also package some useful and successful plugins. I'm so excited about the idea. Let's see how it goes. Thanks to all those who made this possible.
... 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) try: print service.getAPIVersion() except RemotingError, e: print e except error, e: print e
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 ./amf-client.py -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) .