BIRCH/Developer resources/Dale's Ideas

From Bioinformatics.Org Wiki

Overview

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.

1. Dependencies
   1. 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.
   2. This is beyond the scope of what we can do, so we we need to ship BIRCH with its dependencies, and minimize them
   3. Acedb needs to be deprecated.
2. Structure
   1. 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.
   2. Birch lends itself nicely to a client-server relationship model
   3. Birch local could perhaps be replaced by a simpler plugin framework, for BIRCH customization
3. Development model
   1. A more agile approach would offer a much more rapid development pace
   2. 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:

1. Biolegato frontend (the BIRCH client)
2. BIRCH framework backend (the BIRCH server)
3. BIRCH documentation (local and web)
4. BIRCH customization (through a plugin framework)
5. Getbirch BIRCH version manager: getbirch, update BIRCH

There would be two additional developer components of BIRCH:

1. The BIRCH sourcecode (for java files particularly)
2. 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)