meeting critics
raik
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
Timothy Ham
Yes, I think Raik is right in many aspects. If we were all writing to
one common software platform, we'd be much more productive. Maybe we
should discuss this now.
I know that most programmers like to go into a cave for a while, and
come back with great code (maybe). Programmers also seem to have
strong egos which makes leaderless collaborations difficult. Ideally,
we'd all be working on the same code base, but different parts. And to
do that, we need at the minimum a common language. Can we agree on at
least the language? As much as I love working with python, I'd vote
for Java now.
As for Django models, I like having the registry be independent of a
web framework. Because JBEIR (j-bear? Go Bears!) is modular, I was
able to swap out the database layer pretty easily (from dbxml to
mysql--much more difficult than from one sql db to another). In fact,
django is just another layer that hooks to the registry. I swapped out
my crummy cgi handler and html generator with django. BLAST support
was added in a day. Re-writing this to django db model is a step
backwards for me.
Raik, I have studied the Brickit's model.py in the past. It seemed at
that time that there was no easy way to add strains or vectors into
the system and modify the interface to have it make sense. I also felt
that the "business logic" implemented by the BrickIt model was
sufficiently different from ours that modifying it would result in
something that was not BrickIt.
I will try to write a mini-pobol python module this week and post it
here. I've studied it more carefully and I like it.
Tim