[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Calendula-devel] Universal Fundraising DB Standard
[Calendula-devel] Universal Fundraising DB Standard
Wed, 3 Mar 2004 15:01:34 -0500 (EST)
This is Matthew Patton and we traded a few emails in
the past as a result of a software architecture discussion on the Debian
I just read your essay on a "Universal Fundraising DB Standard"
and I thought it was excellent. I very much share your vision for an OSS
system that NGO's can download, modify, and use freely. It would be a
wonderful thing to see such a system become so ubiquitous that it is the
de facto standard and is built up by the collective, unified efforts of an
open source NGO community.
I have some questions for you as you proceed towards this goal.
One is this: you recently put out a screen diagram for how a simple first
version of Calendula would look, and you have mentioned on your mailing
list how you are examining the schema for InfoCentral and ebase2. These
are excellent steps, but I am wondering what thoughts you have on another
important first step that was discussed on the NGO list: what
architecture or framework will you use for your system? The schema and
data structures are one thing to figure out, the architecture is another
(more or less independent) thing.
I know you are thinking the first version will be just a rapid
throw-away prototype that will be mainly for show, but since one of your
main goals is that your system be easily _extensible_, I am sure you well
know that it will be important to think about how you will structure your
programs to make this possible. So I guess my question is: when you say
you are looking for a universal DB solution for NGO's, do you mean your
schema (data structure) is universal or your program architecture (code
structure) is universal? In my opinion, it must be both for real
collaborative effort to take place.
Along the lines of program architecture: at DiscipleMakers, where
another developer and I work full-time, we are currently researching a
possible framework with the same extensibility goals in mind. Here are
our current thoughts:
- It would be optimal to not have to write our own tools to create a
framework for rapidly writing programs. Like you, we see GNUe as not
being in a mature enough state to use right now, so we are thinking of
using the following two relatively mature tools: Zope (www.zope.org) and
- The following is our thoughts as to how we will use these tools: We are
thinking of an n-tier kind of structure:
Web Clients Native GTK Clients Other Clients
(for public interfaces) (for admin interfaces) (curses, etc)
\ / /
RPC RPC RPC
\ / /
Zope serving business logic objects/methods
These methods would be written in python using Modeling as
the Object-relational layer
Modeling's Enterprise Object Framework
/ | \
Various DB's and other data sources
-Zope would take care of all of the complicated server-type stuff
like translating an RPC call into an actual method call and all of the
-Modeling serves to make a common object-oriented way of dealing with data
in the business logic code and to abstract out the actual places and ways
that the data is stored. In other words, no SQL or any knowledge of how
data is actually physically stored in the business logic.
-Having any client (where a client here means a program that uses the
business logic methods) use the same business logic methods is a powerful
abstraction that makes for much more maintainable, reusable, and
extensible code. The clients don't need to know anything except the API
for the Business logic methods.
-The clients would have their own frameworks (probably based on Model View
Controller ideas) based on whether they are Web clients or native apps or
even other kinds like a terminal curses-based client.
We are still working out a lot of the details of these ideas and getting
a sample app going in this architecture using Zope and Modeling, but what
do you think?
If I may offer my suggestion on what would be a useful "universal"
DB solution, it would look like this:
1. It would be universal in that everything would be built on the
same framework using the same basic tools (like Zope and Modeling)
2. It would be universal in that there would be a basic core schema that
would embody the most basic data of the system (e.g., tables for people,
Contact Info, gifts, events, user defined types, stored queries, etc.)
3. It would be universal in that there would be a basic set of code for
accessing and using that schema (basic business logic code, client code)
4. But it would be extensible in that people could build up modules with
additional schema, BL code, and client code that would be interconnected
with the basic schema, BL, and client code based on their particular needs
(for instance, a Conference Registration module could be united to the
core code and use the core code's ability to store common data like
people, but will add another registration-specific data that is linked
with the generic people data). This would mean that the contact managing
CRM-type code would have to be written first and would comprise #3 above.
Thanks for reading this admittedly long-winded description of where we are
at right now. Our current plan is twofold:
1. Code Structure: Hammer out the details of how we will make our program
architecture ideas work with Zope and Modeling and get a sample app
written as proof of concept.
2. Data Structure: Begin designing the schema for the CRM core data
structures based on insights from InfoCentral, GoldMine, ebase2, etc.
I would appreciate any thoughts you may have and we would be very
interested in collaborating with you all who have the same goals as us!
Matthew Patton address@hidden
DiscipleMakers Headquarters: (814)234-7975 x32
|[Prev in Thread]
||[Next in Thread]|
- [Calendula-devel] Universal Fundraising DB Standard,
Matthew Patton <=