BIRCH/Developer resources/Dale's Ideas
From Bioinformatics.Org Wiki
I am writing this article as an analysis of where BIRCH is, and where BIRCH is going.
I want to see BIRCH used on as many systems as possible, by as many people as possible, and as effectively as possible.
As an open source developer if I don't do the best work I can it reflects poorly on my skills. The users of the features that I create are the basis of my reputation as a developer, and I must gear all of my efforts towards making their interactions with my work as simple and intuitive as possible.
Current issues with BIRCH
As a prefix to this section, I want to point out that these issues are not design flaws, but design necessities that are a fundamental part of BIRCH's origins.
- There are too many. We need to do what other open source teams do, and hide this. Package managment systems (Yum, apt, zypper), do automatic dependency fetching.
- This is beyond the scope of what we can do, so we we need to ship BIRCH with its dependencies, and minimize them
- Acedb needs to be deprecated.
- A set of folders on a file system is not a clean way to run a user-space app. All BIRCH server internals should be sorted out and separated from the BIRCH documentation.
- Birch lends itself nicely to a client-server relationship model
- Birch local could perhaps be replaced by a simpler plugin framework, for BIRCH customization
- Development model
- A more agile approach would offer a much more rapid development pace
- Test driven design would save us an incalculable amount of time
A client-server model
Biolegato is the frontend to a BIRCH system
The BIRCH framework is the backend.
The BIRCH framework needs to be re-written in python anyways, so this is the perfect time to structure it as a server to BIRCH services.
Essentially, this would be modularizing what we call BIRCH now into 5 components:
- Biolegato frontend (the BIRCH client)
- BIRCH framework backend (the BIRCH server)
- BIRCH documentation (local and web)
- BIRCH customization (through a plugin framework)
- Getbirch BIRCH version manager: getbirch, update BIRCH
There would be two additional developer components of BIRCH:
- The BIRCH sourcecode (for java files particularly)
- The BIRCH testing framework (important for the python scripts, but should eventually include GUI tests of biolegato)
This would make BIRCH as a multi-user system simple and efficient for the end-user.
Either they install birch standalone (server+client on same system), or opt for a network install (server+remote client)