[Calendula-devel] DiscipleMakers weigh-in
Matthew Patton
pattonm@dm.org
Thu, 18 Mar 2004 17:43:12 -0500 (EST)
Hi Darryl et al,
Tom Hallman and I (two full-time developers) work for a Christian
Campus ministry called DiscipleMakers, and we have a need for a software
package like Calendula for managing our supporters, and we are committed
to working towards an open source solution to our needs. We have made
some decisions recently regarding our future development work that I
wanted to share with you all.
To begin meeting our needs, we have been developing for some time
an enterprise application toolkit that will enable us to write the
software we need. There is a first generation version of this available
at doulos.sourceforge.net that we have successfully used to create and
deploy a Conference Registration application. However, what you will find
there is far inferior to what we have been researching and planning for
the past several months. Doulos is a PHP Web Application Framework. Our
current work will be to create an enterprise application toolkit (yet to
be named, sourceforge page coming very soon) that will be written
primarily in python. I have explained this at length in a previous post
which I can resend to any who are interested (no archives anymore of old
mailing list, Darryl?).
You are probably groaning right now and writing us off as dreamers
who won't have anything workable in a long time. However, we are taking
the approach that if anything else is already written, don't rewrite it.
Below is an overview of our architecture as we currently have conceived
it, with the parts that are already written (i.e., other mature projects)
specified:
Client (web client, native app client, etc)
-View (HTML, GTK, etc.)
-Control (code that calls business logic)
|
RPC Protocol (our own super-protocol that would extend a lower protocol
like XML-RPC to enable objects to be sent back and forth)
-Client Translator
-Lower level RPC protocol (either XML-RPC (nice python library already
written, xmlrpclib), SOAP, etc. or just a direct local call)
-Server Translator
|
Server (running in Zope or just used as a local library)
-Business Logic Framework (code that uses modeling and other data access
layers)
-Modeling (modeling.sourceforget.net) object/relational bridge, other
Data source-to-object layers
|
Low Level Data Sources
-DB's, LDAP, etc. (where the data is actually stored, these are already
written (MySQL, Postgres, etc))
Since we are using powerful, mature tools like Zope, Modeling, xmlrpclib,
and Open Source DB's, our todo list is just the relatively lightweight
frameworks and glue layers to make the hefty tools work together. The
total list is:
1. Client Frameworks
I know of one good GTK possibility that I have to research more, and
there are many good Python Web Application Frameworks that can possibly
be tweaked for our needs, so I am hoping not to need to write these. But
even if I do, I have a lot of experience from writing Doulos and could
develop a web app framework quickly enough.
2. Client/Server Translators
These will enable us to speak our high-level protocol and that will
expand just slightly basic RPC protocols like XML-RPC. These will be
very thin and very lightweight.
3. Business Logic Framework
This defines the basic API for interacting on a high level with the
low-level data storage software (like SQL DB's). This is also going to be
quite lightweight and will just offer some handy abstractions for writing
common business logic code. Modeling, a relational DB to object mapper
for python, will do most of the work for us and save us from writing a
line of SQL.
Since these three things are so small, we could have the first version of
the tools that we need in short order (hopefully a month or two) and start
writing the REAL code.
As for this REAL code, the real code that we need the soonest is a
replacement for our current receipting system. As a result, we will be
developing this first and using it as real-life test case for our
enterprise application toolkit. The tools will really be worth using
after they have gone through the rigors of their first application, and
this app isn't going to be too big, so it won't be too long before the
tools reach this maturity (hopefully several months).
I see this receipting system as being a module for the core CRM
that you are looking to develop, and they could be easily merged, but only
if we work from the same toolkit. So I wanted to let you all know that
this is a possibility, and see what you thought.
Thanks,
Matt
______________________________________________________________
Matthew Patton pattonm@dm.org
DiscipleMakers Headquarters: (814)234-7975 x32