[Brickit] meeting critics

[Raik G. <rai...@cr...>]

Hi again,

I tried to give a neutral summary of our tele-meeting in my previous mail to the 
pobol@ group but I am actually not entirely satisfied about the outcome and 
would like to raise some critics. Sorry for being a bit out of focus and not 
bringing those up during the call itself...

It was excellent to get an overview over the different development efforts -- 
having a discussion group around these topics was definitely a good idea and 
perhaps we should broaden it beyond Pobol and registry issues. However, the 
eventual conclusion was that we all keep on developing our software tools 
independently and promote Pobol as a connectivity standard. That's less than I 
had hoped for. To repeat the comment from the review, it's ironic that wet lab 
synthetic biologists are good at building libraries and exchanging parts against 
technical and legal odds, whereas their computer colleagues keep on working in 
closed groups or even alone.

I also led slip through some miss-conceptions about BrickIt. The project is not 
developed "in vacuum" but is actually in real-world use. Even though it right 
now only handles 200 or so BioBricks and samples, the data model already went 
through several iterations of modifications and testing to suit our wet lab 
needs. So, Tim, please have a look at the BrickIt data model! In fact, models.py 
is the only thing that is really important about the existing code. All the 
other aspects (project layout, web interface) are just rough attempts to get up 
and running as quickly as possible. So you are right that one shouldn't use the 
admin interface for public viewing. In fact, I think one should develop a 
completely independent set of views and forms (which is how django projects 
work). The problem is that I don't really have the expertise for that. The devel 
branch of the svn contains a pretty nice BioBrick view which I tried to merge 
into the admin interface but that's a rather complicate strategy and one should 
really start from scratch there.

There are also some issues with the JBEI registry architecture though. So you 
guys are using the Django templating system but refrained from using the Django 
data API and have some custom XML / mySQL layer underneath. But why? This layout 
is not more but rather less modular than a pure django solution. For example, if 
you would use the full django stack, you could rather easily migrate your DB 
from mySQL to Postgresql or Oracle or whatever whithout changing any of your 
code (which I actually did with BrickIt). Moreover, the django data API is one 
of the main advantages of the whole framework. It makes it incredibly intuitive 
to access the data even for programmers that have never used django before. And 
given the rising popularity of django and given that Google has chosen the same 
API for their AppEngine platform, this API is now turning into something like an 
industry standard (well, or as close as it gets in the splintered world of web 
development).
Chris, Tim, it is really great that you want to open up your registry software 
-- I would be the first to switch over if the result turns out well. But then 
you should make it as easy as possible for outside developers to join the 
project. Yet another custom API creates a high barrier.

What I would like to see in the scene is some real software development 
collaboration. So here are my suggestions: Doug, why don't you guys set up an 
open source synbio java library? Some of your clotho code about BioBrick 
handling is certainly of more general use. Tim, we could start the same for the 
Python side. Of course, even more I would prefer if we could compare the needs 
and data structure of your JBEI registry and BrickIt and explore whether the two 
could be merged.

Despite the very little time left for programming right now,  what I still plan 
to get done is to finalize the last tweaks to the brickit data model, to clean 
up the brickit folder structure and then to merge the cleaned devel version back 
into the trunk. This should give you a better starting point for having another 
look at it.

Sorry about the long discourse!
Greetings,
Raik

-- 
________________________________

Dr. Raik Gruenberg
http://www.raiks.de/contact.html
________________________________