From darrylc@fudosys.com Thu Mar 11 17:35:21 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 5BA126DD4 for ; Thu, 11 Mar 2004 17:35:21 -0600 (CST) From: Darryl Caldwell To: caldev Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079048079.1306.13.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 11 Mar 2004 15:34:39 -0800 Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] data migration Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Does anyone on the list have experience with migrating data from FileMaker and/or MS Access? I am looking ahead to import/export issues. And are there any more comments on the diagram? -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From creede@penguinsinthenight.com Thu Mar 11 17:49:46 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id D8D7E6DDE; Thu, 11 Mar 2004 17:49:46 -0600 (CST) Received: from igor.penguinsinthenight.com (c-24-18-220-54.client.comcast.net [24.18.220.54]) by riposte.org (Postfix) with ESMTP id C82706DD4; Thu, 11 Mar 2004 17:49:14 -0600 (CST) Received: by igor.penguinsinthenight.com (Postfix, from userid 1000) id 860CE20A38D; Thu, 11 Mar 2004 15:48:26 -0800 (PST) Date: Thu, 11 Mar 2004 15:48:26 -0800 From: Creede Lambard To: Darryl Caldwell Cc: caldev Subject: Re: [Calendula-devel] data migration Message-ID: <20040311234826.GE9809@igor.penguinsinthenight.com> References: <1079048079.1306.13.camel@dhcppc4> In-Reply-To: <1079048079.1306.13.camel@dhcppc4> X-Spook: /usr/local/bin/spook User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-11.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary=1LKvkjL3sHcu1TtY Content-Disposition: inline Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I don't have experience, but I do have Google. http://starship.python.net/crew/bwilk/access.html This page admits to being somewhat outdated but might give some pointers as to how to read an Access database from Python. Unfortunately you apparently have to do this on a machine with a Jet DB engine running, which means Windows; fortunately it looks like SQL is available in the queries (at least the example given contains a SQL query). Ideally there would be a native Python module that would read Access and FileMaker tables (maybe even entire databases) and spit them back out in CSV or some other easily exportable format. On Thu, Mar 11, 2004 at 03:34:39PM -0800, Darryl Caldwell wrote: > Does anyone on the list have experience with migrating data from > FileMaker and/or MS Access? >=20 > I am looking ahead to import/export issues. >=20 > And are there any more comments on the diagram? >=20 > -D >=20 > --=20 > Darryl Caldwell darrylc@fudosys.com > Fudo Systems www.fudosys.com > 206/567-5802 "Free Your Computers!" >=20 > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * .~. ( : Creede Lambard : Never rush a miracle man. . / V \ . :------------------------: You get lousy miracles. /( )\ : creede at : --------------------------------^^-^^----: penguinsinthenight : =20 Linux. Reliable and free. Pick any two. : dot com : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAUPrK6RaRqmjNX/0RApXIAJ9tjqt9hNsflkXIdbQVWF9W6Lfu0gCeIYVQ eFKxBqMC+tphAFhEI9+yI1M= =QbxA -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From TPanzarella@fcny.org Fri Mar 12 07:32:20 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id CDC446DDD; Fri, 12 Mar 2004 07:32:20 -0600 (CST) Received: from mail.fcny.org (unknown [209.11.29.190]) by riposte.org (Postfix) with ESMTP id 0E7CE6DD4; Fri, 12 Mar 2004 07:31:48 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Calendula-devel] data migration Date: Fri, 12 Mar 2004 08:31:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Calendula-devel] data migration Thread-Index: AcQHw5LuyBy1bpukQ2KmjemJW9slNgAciMmQ From: "Thomas Panzarella" To: "Creede Lambard" , "Darryl Caldwell" Cc: "caldev" X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: I'm not familiar with FileMaker (and only vaguely familiar with Access), but on the Access front you could use a product like http://www.mysql.com/portal/software/item-98.html to convert the Access DB to MySQL and then from MySQL you can pretty much take it anywhere (or leave it there since MySQL is mature and robust -- IMHO). Also, I know Access can be used as an ODBC data source (maybe file maker can too???) -- so why not "roll your own" export utility? -- for example in Java you could use the freely supplied JDBC/ODBC bridge and pull data from access to whatever you want using standard JDBC. Does Python have some type of bridging driver to ODBC? Since it seems Python is your lang of choice, I'd check that out. t. > -----Original Message----- > From: Creede Lambard [mailto:creede@penguinsinthenight.com] > Sent: Thursday, March 11, 2004 6:48 PM > To: Darryl Caldwell > Cc: caldev > Subject: Re: [Calendula-devel] data migration >=20 >=20 > I don't have experience, but I do have Google. >=20 > http://starship.python.net/crew/bwilk/access.html >=20 > This page admits to being somewhat outdated but might give=20 > some pointers as > to how to read an Access database from Python. Unfortunately=20 > you apparently > have to do this on a machine with a Jet DB engine running, which means > Windows; fortunately it looks like SQL is available in the=20 > queries (at least > the example given contains a SQL query). >=20 > Ideally there would be a native Python module that would read=20 > Access and > FileMaker tables (maybe even entire databases) and spit them=20 > back out in CSV > or some other easily exportable format. >=20 > On Thu, Mar 11, 2004 at 03:34:39PM -0800, Darryl Caldwell wrote: > > Does anyone on the list have experience with migrating data from > > FileMaker and/or MS Access? > >=20 > > I am looking ahead to import/export issues. > >=20 > > And are there any more comments on the diagram? > >=20 > > -D > >=20 > > --=20 > > Darryl Caldwell darrylc@fudosys.com > > Fudo Systems www.fudosys.com > > 206/567-5802 "Free Your Computers!" > >=20 > > _______________________________________________ > > Calendula-devel mailing list > > Calendula-devel@fudosys.com > > http://list.fudosys.com/mailman/listinfo/calendula-devel >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * .~. ( : Creede Lambard : > Never rush a miracle man. . / V \ . :------------------------: > You get lousy miracles. /( )\ : creede at : > --------------------------------^^-^^----: penguinsinthenight :=20=20 > Linux. Reliable and free. Pick any two. : dot com : > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 From bill-bell@bill-bell.hamilton.on.ca Fri Mar 12 08:07:12 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 00AEF6DDD; Fri, 12 Mar 2004 08:07:11 -0600 (CST) Received: from smaug.vex.net (unknown [66.246.136.211]) by riposte.org (Postfix) with ESMTP id 42FCA6DD4 for ; Fri, 12 Mar 2004 08:06:39 -0600 (CST) Received: from default (Hamilton-ppp67796.sympatico.ca [216.208.50.129]) by smaug.vex.net (Postfix) with ESMTP id 9941826A33; Fri, 12 Mar 2004 09:06:26 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: calendula-devel@gnu.org Date: Fri, 12 Mar 2004 09:06:13 -0500 Subject: RE: [Calendula-devel] data migration Reply-To: bill-bell@bill-bell.hamilton.on.ca Cc: "caldev" , "Thomas Panzarella" Message-ID: <40517D85.16264.3B757E8@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 12 Mar 2004 at 8:31, Thomas Panzarella wrote: > I'm not familiar with FileMaker (and only vaguely familiar with Access), > but on the Access front you could use a product like > http://www.mysql.com/portal/software/item-98.html to convert the Access > DB to MySQL and then from MySQL you can pretty much take it anywhere (or > leave it there since MySQL is mature and robust -- IMHO). > > Also, I know Access can be used as an ODBC data source (maybe file maker > can too???) -- so why not "roll your own" export utility? -- for example > in Java you could use the freely supplied JDBC/ODBC bridge and pull data > from access to whatever you want using standard JDBC. Does Python have > some type of bridging driver to ODBC? Since it seems Python is your > lang of choice, I'd check that out. Hello, all: I haven't been following this thread, and I haven't posted to this list before, which explains why I'm copying to some individuals: I'm not sure I have the right address for the list. I've worked with both FM and Access. Both support ODBC, and Python offers convenient access to ODBC. IIRC, FM's ODBC is wobbly, and as a consequence I have retrieved data from FM tables as HTML files, then parsed them. Access's ODBC has never given me trouble, and I've used it heavily, on and off, for some years. Here is some Python code to read from an Access database using ODBC. In this case Python reads from a table called "Students". It's just as easy to read from a virtual table defined with a SQL statement. # code starts here ============================== from win32com . client import Dispatch from smtplib import SMTP conn = Dispatch ( r'ADODB.Connection' ) connString = r'PROVIDER=Microsoft.Jet.OLEDB.4.0;DATA SOURCE=E:\1P97\Master\students.mdb' conn.Open ( connString ) rs = Dispatch ( r'ADODB.Recordset' ) server = SMTP ( 'smtp.vex.net', 425 ) server . set_debuglevel ( 1 ) server . login ( 'wbell', '*******' ) rs.Open ( "[students]", conn, 1, 3 ) while not rs . EOF : for addressField in [ 'email1', 'email2' ] : if rs . Fields ( addressField ) . Value : toaddr = rs . Fields ( addressField ) . Value server . sendmail ( 'bill@softwaregeneralist.ca', toaddr, """ \ Subject: Your ITIS 1P97 assignment submission code I'm sending this message to everyone in my section of ITIS 1P97. Your code is %s. Please bring it with you to every laborary session. Perhaps you could write it on a slip of paper that you keep in your billfold or handbag? Thanks. Bill Bell """ % rs . Fields ( 'code' ) . Value ) #~ break rs . Move ( 1 ) rs . Close ( ) server . quit ( ) # code ends here ============================== Would someone mind restating the problem to be solved? Best regards, Bill From darrylc@fudosys.com Fri Mar 12 11:08:44 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from www.fudosys.com (localhost.localdomain [127.0.0.1]) by riposte.org (Postfix) with SMTP id 1CD4D6DD4 for ; Fri, 12 Mar 2004 11:08:44 -0600 (CST) Received: from 64.38.163.140 (SquirrelMail authenticated user darrylc@fudosys.com) by webmail.fudosys.com with HTTP; Fri, 12 Mar 2004 09:08:44 -0800 (PST) Message-ID: <34725.64.38.163.140.1079111324.squirrel@webmail.fudosys.com> In-Reply-To: <40517D85.16264.3B757E8@localhost> References: <40517D85.16264.3B757E8@localhost> Date: Fri, 12 Mar 2004 09:08:44 -0800 (PST) Subject: RE: [Calendula-devel] data migration From: "Darryl Caldwell" To: calendula-devel@fudosys.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Bill, Bill, Bill, where were you when I needed your expertise last year? ;-) Thanks for that great code snippet. I can see putting that to use REAL SOON. The problem to be solved is to start planning for migration of data in FM and Access databases over to Calendula. Thomas and others have suggested that many small nonprofits use FM and Access to store their donor data. Some type of migration tools should be present early on and I want to make sure the path is mapped out. -D > > Hello, all: > > I haven't been following this thread, and I haven't posted to this list > before, which > explains why I'm copying to some individuals: I'm not sure I have the > right address > for the list. > > I've worked with both FM and Access. Both support ODBC, and Python offers > convenient access to ODBC. IIRC, FM's ODBC is wobbly, and as a consequence > I > have retrieved data from FM tables as HTML files, then parsed them. > Access's > ODBC has never given me trouble, and I've used it heavily, on and off, for > some > years. > == Code sample snipped == > > Would someone mind restating the problem to be solved? > -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From darrylc@fudosys.com Fri Mar 12 11:26:31 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from www.fudosys.com (localhost.localdomain [127.0.0.1]) by riposte.org (Postfix) with SMTP id 313B06DD4 for ; Fri, 12 Mar 2004 11:26:31 -0600 (CST) Received: from 64.38.163.140 (SquirrelMail authenticated user darrylc@fudosys.com) by webmail.fudosys.com with HTTP; Fri, 12 Mar 2004 09:26:31 -0800 (PST) Message-ID: <34741.64.38.163.140.1079112391.squirrel@webmail.fudosys.com> Date: Fri, 12 Mar 2004 09:26:31 -0800 (PST) From: "Darryl Caldwell" To: calendula-devel@fudosys.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: [Calendula-devel] Everyone has been unsubscribed from gnu list Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: You may have just received the goodbye msg from the gnu list. I just unsubscribed us all from there. Direct all your posts to calendula-devel@fudosys.com from now on. Thanks. -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From creede@penguinsinthenight.com Fri Mar 12 11:42:49 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 1CC076DD4; Fri, 12 Mar 2004 11:42:49 -0600 (CST) Received: from igor.penguinsinthenight.com (c-24-18-220-54.client.comcast.net [24.18.220.54]) by riposte.org (Postfix) with ESMTP id CF2786DDD; Fri, 12 Mar 2004 11:42:16 -0600 (CST) Received: by igor.penguinsinthenight.com (Postfix, from userid 1000) id 5032120C47F; Fri, 12 Mar 2004 09:42:13 -0800 (PST) Date: Fri, 12 Mar 2004 09:42:13 -0800 From: Creede Lambard To: Darryl Caldwell Cc: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] data migration Message-ID: <20040312174213.GK9809@igor.penguinsinthenight.com> References: <40517D85.16264.3B757E8@localhost> <34725.64.38.163.140.1079111324.squirrel@webmail.fudosys.com> In-Reply-To: <34725.64.38.163.140.1079111324.squirrel@webmail.fudosys.com> X-Spook: /usr/local/bin/spook User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-11.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The problem as I see it is that unless these databases are from programs wi= th standardized formats, you are going to have a bunch of tables slapped together and won't know programmatically which field represents which information in Calendula's database. I guess you could migrate data to CSV files and then have a tool to import the CSV information by specifying which FM/Access field maps to which Calendula field, but I don't think even that = is as straightforward as it sounds. Not to say we shouldn't do it, of course. Just saying it's going to require some skullsweat before the code gets written. On Fri, Mar 12, 2004 at 09:08:44AM -0800, Darryl Caldwell wrote: > Bill, Bill, Bill, where were you when I needed your expertise last year? = ;-) >=20 > Thanks for that great code snippet. I can see putting that to use REAL > SOON. The problem to be solved is to start planning for migration of data > in FM and Access databases over to Calendula. Thomas and others have > suggested that many small nonprofits use FM and Access to store their > donor data. Some type of migration tools should be present early on and I > want to make sure the path is mapped out. >=20 > -D --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * .~. ( : Creede Lambard : Never rush a miracle man. . / V \ . :------------------------: You get lousy miracles. /( )\ : creede at : --------------------------------^^-^^----: penguinsinthenight : =20 Linux. Reliable and free. Pick any two. : dot com : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFAUfZ06RaRqmjNX/0RAiiTAJdr5pvSeGMW9cPx+rkwimXpBktBAJ9CzfZI AyoOxgIrGsZrZe7R0pttcQ== =2rNN -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From TPanzarella@fcny.org Fri Mar 12 11:44:33 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id B61606DD4; Fri, 12 Mar 2004 11:44:33 -0600 (CST) Received: from mail.fcny.org (unknown [209.11.29.190]) by riposte.org (Postfix) with ESMTP id 030F26DDD for ; Fri, 12 Mar 2004 11:44:02 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Calendula-devel] data migration Date: Fri, 12 Mar 2004 12:44:01 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Calendula-devel] data migration Thread-Index: AcQIVLssN/fABdIkSBWSpQr94eeHvQAAzatg From: "Thomas Panzarella" To: X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: With all of the Calendula movement (list, etc.) could you (Darryl) quickly = send out an email that says where the lists are, where the CVS is located, = and any other pertinent info for contributors? Also, at this point, I think we should turn discussions to finializing requ= irements, building a clear project plan document, and building out technica= l specifications -- I'd suggest we try to stick with some "standards" when = trying to communicate technical aspects of the project (i.e. UML Diagrams, = Use Cases, etc.). I feel sort of lost as to how to intelligently contribut= e here. We are talking data migration but what is the context? We looked = at a code snippet that connects to a database but, (again) what is the cont= ext? Who on this list is heading to Philly for NTEN? I propose a meetup of peop= le interested in the Calendula project to sit and discuss some details. I = will volunteer myself to draft up "minutes", so to speak, from that meeting= to communicate back to the group at large. Eventhough this is the "less f= un part" of open source, we need to work out the politics of how the "calen= dula community" is going to work. Set up a "board" ... who is "code captai= n", who is "zealot", who will maintain a bug database, who will maintain th= e list servs / cvs / etc., who is a "comitter" to cvs, who will set up - ma= intain - and make look pretty/professional the calendula project web site, = etc. There are many issues that need to get worked out ... I am going to a= ssume that Darryl does not want to take on all of those roles. t. > -----Original Message----- > From: Darryl Caldwell [mailto:darrylc@fudosys.com] > Sent: Friday, March 12, 2004 12:09 PM > To: calendula-devel@fudosys.com > Subject: RE: [Calendula-devel] data migration >=20 >=20 > Bill, Bill, Bill, where were you when I needed your expertise=20 > last year? ;-) >=20 > Thanks for that great code snippet. I can see putting that to use REAL > SOON. The problem to be solved is to start planning for=20 > migration of data > in FM and Access databases over to Calendula. Thomas and others have > suggested that many small nonprofits use FM and Access to store their > donor data. Some type of migration tools should be present=20 > early on and I > want to make sure the path is mapped out. >=20 > -D >=20 >=20 > > > > Hello, all: > > > > I haven't been following this thread, and I haven't posted=20 > to this list > > before, which > > explains why I'm copying to some individuals: I'm not sure=20 > I have the > > right address > > for the list. > > > > I've worked with both FM and Access. Both support ODBC, and=20 > Python offers > > convenient access to ODBC. IIRC, FM's ODBC is wobbly, and=20 > as a consequence > > I > > have retrieved data from FM tables as HTML files, then parsed them. > > Access's > > ODBC has never given me trouble, and I've used it heavily,=20 > on and off, for > > some > > years. > > > =3D=3D Code sample snipped =3D=3D > > > > Would someone mind restating the problem to be solved? > > >=20 >=20 > --=20 > Darryl Caldwell > darrylc@fudosys.com > www.fudosys.com > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel >=20 From TPanzarella@fcny.org Fri Mar 12 11:49:01 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 80E916DDD; Fri, 12 Mar 2004 11:49:01 -0600 (CST) Received: from mail.fcny.org (unknown [209.11.29.190]) by riposte.org (Postfix) with ESMTP id CC7B66DD4 for ; Fri, 12 Mar 2004 11:48:29 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Calendula-devel] data migration Date: Fri, 12 Mar 2004 12:48:29 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Calendula-devel] data migration Thread-Index: AcQIWXg3RDIvSc+RRkyw2wqJsQXa1wAADlTw From: "Thomas Panzarella" To: X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Agreed. The way that I think this is best attacked is to create a clear specification on a data import file format or API. Then have individuals who have a personal stake in writing, for example, a Raiser's Edge to Calendula data migration tool to build the driver that will extract from RE into the Calendula's published import format and then run the Calendula import tools against that file or set of files to import the data. Much easier on the Calendula side and promotes community and could ultimately mean support for many more systems in the end... t. > -----Original Message----- > From: Creede Lambard [mailto:creede@penguinsinthenight.com] > Sent: Friday, March 12, 2004 12:42 PM > To: Darryl Caldwell > Cc: calendula-devel@fudosys.com > Subject: Re: [Calendula-devel] data migration >=20 >=20 > The problem as I see it is that unless these databases are=20 > from programs with > standardized formats, you are going to have a bunch of tables slapped > together and won't know programmatically which field represents which > information in Calendula's database. I guess you could=20 > migrate data to CSV > files and then have a tool to import the CSV information by=20 > specifying which > FM/Access field maps to which Calendula field, but I don't=20 > think even that is > as straightforward as it sounds. >=20 > Not to say we shouldn't do it, of course. Just saying it's=20 > going to require > some skullsweat before the code gets written. >=20 > On Fri, Mar 12, 2004 at 09:08:44AM -0800, Darryl Caldwell wrote: > > Bill, Bill, Bill, where were you when I needed your=20 > expertise last year? ;-) > >=20 > > Thanks for that great code snippet. I can see putting that=20 > to use REAL > > SOON. The problem to be solved is to start planning for=20 > migration of data > > in FM and Access databases over to Calendula. Thomas and others have > > suggested that many small nonprofits use FM and Access to=20 > store their > > donor data. Some type of migration tools should be present=20 > early on and I > > want to make sure the path is mapped out. > >=20 > > -D >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * .~. ( : Creede Lambard : > Never rush a miracle man. . / V \ . :------------------------: > You get lousy miracles. /( )\ : creede at : > --------------------------------^^-^^----: penguinsinthenight :=20=20 > Linux. Reliable and free. Pick any two. : dot com : > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 From bill-bell@bill-bell.hamilton.on.ca Fri Mar 12 16:23:15 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 8609C6DDD; Fri, 12 Mar 2004 16:23:15 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id A1A716DD4; Fri, 12 Mar 2004 16:22:43 -0600 (CST) Received: from default (Hamilton-ppp106896.sympatico.ca [216.209.129.113]) by smaug.vex.net (Postfix) with ESMTP id 3B8A425A01; Fri, 12 Mar 2004 17:22:40 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: "Darryl Caldwell" , calendula-devel@fudosys.com Date: Fri, 12 Mar 2004 17:22:29 -0500 Subject: RE: [Calendula-devel] data migration Reply-To: bill-bell@bill-bell.hamilton.on.ca Message-ID: <4051F1D5.23881.57DB0C8@localhost> Priority: normal In-reply-to: <34725.64.38.163.140.1079111324.squirrel@webmail.fudosys.com> References: <40517D85.16264.3B757E8@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 12 Mar 2004 at 9:08, Darryl Caldwell wrote: > Bill, Bill, Bill, where were you when I needed your expertise last year? ;-) Appearances to the contrary notwithstanding, my life is not all laughs and excitement. I was probably sitting in this very chair last year staring at this very screen. :o) > The problem to be solved is to start planning for migration of data > in FM and Access databases over to Calendula. ... Thanks for the summary! Bill From darrylc@fudosys.com Sun Mar 14 16:00:57 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from fudosys.com (localhost.localdomain [127.0.0.1]) by riposte.org (Postfix) with SMTP id E1E5E6DDD for ; Sun, 14 Mar 2004 16:00:56 -0600 (CST) Received: from 207.254.100.206 (SquirrelMail authenticated user darrylc@fudosys.com) by webmail.fudosys.com with HTTP; Sun, 14 Mar 2004 14:00:56 -0800 (PST) Message-ID: <18067.207.254.100.206.1079301656.squirrel@webmail.fudosys.com> Date: Sun, 14 Mar 2004 14:00:56 -0800 (PST) From: "Darryl Caldwell" To: calendula-devel@fudosys.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal References: In-Reply-To: Subject: [Calendula-devel] construction plans to date Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: > With all of the Calendula movement (list, etc.) could you (Darryl) quickly > send out an email that says where the lists are, where the CVS is located, > and any other pertinent info for contributors? Quicker than quick! I've just spent 2 days at a YMCA development conference, breaking bread with fundraisers and spying on all of the proprietary software vendors. I encourage everyone who does not currently have a relationship with a nonprofit/charity to do this. It is well worth getting a peak at the requirement from their side; and let me tell you that cultivation of donors is key to getting their funding. Calendula shall be key to this process. So here are a few quick details requested by Thomas: Calendula Project: https://savannah.gnu.org/projects/calendula/ Calendula is part of the gnu project. Developers can get accounts here and receive contributor status. This is also the easiest way to view and access the cvs repository. This will change again and again, of course. Please visit and get an account. This will be your first step. In CVS you will find: REQ -- requirements doc ROADMAP - skeletal survey_questions -- survey for end-users universal_article - the business case article for Calendula database - directory contains: db schema in postgres format, OpenOffice diagram of the db tables. All of this needs updating and warts removed. Calendula Development mailing list: http://list.fudosys.com/mailman/listinfo/calendula-devel UI workflow diagram can be viewed at: http://fudosys.com/calendula-diagram.png I will be adding it to CVS soon. Here is the list of potential coders: Me Creede L. Thomas P. David G. And potential collaborators from DicipleMakers: Matthew P. Jason M. Tom H. Brian R. Some arms may need twisting from the list above. Now regarding the context of the database migration discussion I started it simply to get an idea of a possible migration path and how this would impact the early stages of the project. We will revisit it later on. I don't want anyone to feel stuck or lost. Squeaky wheels will get greased. If no one but Tom P. is going to N-TEN, we could schedule a conference call to act on "who owns what". And I could get started with Mr. Project.... -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 06:53:08 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 8C0D06DDD; Mon, 15 Mar 2004 06:53:08 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id DE3976DD4 for ; Mon, 15 Mar 2004 06:52:36 -0600 (CST) Received: from default (Hamilton-ppp67807.sympatico.ca [216.208.50.140]) by smaug.vex.net (Postfix) with ESMTP id 396482506C for ; Mon, 15 Mar 2004 07:52:35 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: calendula-devel@fudosys.com Date: Mon, 15 Mar 2004 07:52:38 -0500 Subject: Re: [Calendula-devel] construction plans to date Reply-To: bill-bell@bill-bell.hamilton.on.ca Message-ID: <405560C6.5270.12E70BA1@localhost> Priority: normal In-reply-to: <18067.207.254.100.206.1079301656.squirrel@webmail.fudosys.com> References: X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 14 Mar 2004 at 14:00, Darryl Caldwell wrote, in part: > > So here are a few quick details requested by Thomas: > > Calendula Project: > > https://savannah.gnu.org/projects/calendula/ I've reviewed some of the project documents. Has there been any discussion about what the main coding language will be? Bill From tpanzarella@mac.com Mon Mar 15 07:18:21 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id C24356DDD; Mon, 15 Mar 2004 07:18:21 -0600 (CST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by riposte.org (Postfix) with ESMTP id F397E6DD4 for ; Mon, 15 Mar 2004 07:17:48 -0600 (CST) Received: from webmail18.mac.com (webmail18-en1 [10.13.10.160]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i2FDHmRW015779 for ; Mon, 15 Mar 2004 05:17:48 -0800 (PST) Received: from webmail18 (localhost [127.0.0.1]) by webmail18.mac.com (8.12.6/8.12.2) with ESMTP id i2FDHlCL020138 for ; Mon, 15 Mar 2004 05:17:47 -0800 (PST) Message-ID: <15226085.1079356667545.JavaMail.tpanzarella@mac.com> Date: Mon, 15 Mar 2004 08:17:47 -0500 From: Thomas Panzarella To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] construction plans to date X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10 version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: I believe that Darryl wanted to implement (at least the prototype) in Python. Is this set in stone? t. On Monday, March 15, 2004, at 07:52AM, Bill Bell wrote: > >On 14 Mar 2004 at 14:00, Darryl Caldwell wrote, in part: >> >> So here are a few quick details requested by Thomas: >> >> Calendula Project: >> >> https://savannah.gnu.org/projects/calendula/ > >I've reviewed some of the project documents. Has there been any discussion about >what the main coding language will be? > >Bill >_______________________________________________ >Calendula-devel mailing list >Calendula-devel@fudosys.com >http://list.fudosys.com/mailman/listinfo/calendula-devel > > From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 07:41:18 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 037BF6DDD; Mon, 15 Mar 2004 07:41:17 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id 6E93C6DD4 for ; Mon, 15 Mar 2004 07:40:45 -0600 (CST) Received: from default (Hamilton-ppp67807.sympatico.ca [216.208.50.140]) by smaug.vex.net (Postfix) with ESMTP id B42A0260D1 for ; Mon, 15 Mar 2004 08:40:43 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: calendula-devel@fudosys.com Date: Mon, 15 Mar 2004 08:40:47 -0500 Subject: Re: [Calendula-devel] construction plans to date Reply-To: bill-bell@bill-bell.hamilton.on.ca Message-ID: <40556C0F.11354.13132159@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Thomas Panzarella > I believe that Darryl wanted to implement (at least the prototype) in > Python. Is this set in stone? I do not want to impose my preferences on others. However, I'm up to speed with Python and wxPython, and I'd be a willing participant. Bill PS: Recipes: http://aspn.activestate.com/ASPN/Cookbook/Python (search for "Bill Bell" with quotation marks) http://wiki.wxpython.org/index.cgi/FindPage?action=fullsearch&value=Bill+Bell&conte xt=40 http://www.zopelabs.com/cookbook/1054211661 From tpanzarella@mac.com Mon Mar 15 07:52:36 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id B3F436DDD; Mon, 15 Mar 2004 07:52:36 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-86.apple.com [17.250.248.86]) by riposte.org (Postfix) with ESMTP id D41A66DD4 for ; Mon, 15 Mar 2004 07:51:59 -0600 (CST) Received: from webmail18.mac.com (webmail18-en1 [10.13.10.160]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i2FDpwiv029226 for ; Mon, 15 Mar 2004 05:51:58 -0800 (PST) Received: from webmail18 (localhost [127.0.0.1]) by webmail18.mac.com (8.12.6/8.12.2) with ESMTP id i2FDpwCL020714 for ; Mon, 15 Mar 2004 05:51:58 -0800 (PST) Message-ID: <3152748.1079358718555.JavaMail.tpanzarella@mac.com> Date: Mon, 15 Mar 2004 08:51:58 -0500 From: Thomas Panzarella To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] construction plans to date X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: I too can deal with Python. But I must say, that I am inclined to think that a compiled language with strong typing would be preferred for a project of this scope. Also, I think much more important that the ultimate language is the architecture. A well designed object model and the use of patterns will pay off many times over in the end. If the design is done right, we could code this in any language that supports OO -- if I'm not mistaken, GetActive is coded in TCL and look at the success there! t. On Monday, March 15, 2004, at 08:40AM, Bill Bell wrote: > >Thomas Panzarella > >> I believe that Darryl wanted to implement (at least the prototype) in >> Python. Is this set in stone? > >I do not want to impose my preferences on others. However, I'm up to speed with >Python and wxPython, and I'd be a willing participant. > >Bill > >PS: Recipes: > >http://aspn.activestate.com/ASPN/Cookbook/Python (search for "Bill Bell" with >quotation marks) > >http://wiki.wxpython.org/index.cgi/FindPage?action=fullsearch&value=Bill+Bell&conte >xt=40 > >http://www.zopelabs.com/cookbook/1054211661 >_______________________________________________ >Calendula-devel mailing list >Calendula-devel@fudosys.com >http://list.fudosys.com/mailman/listinfo/calendula-devel > > From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 08:11:55 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 9DA6B6DDD; Mon, 15 Mar 2004 08:11:55 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id 0A2136DD4 for ; Mon, 15 Mar 2004 08:11:24 -0600 (CST) Received: from default (Hamilton-ppp67807.sympatico.ca [216.208.50.140]) by smaug.vex.net (Postfix) with ESMTP id 2CD3326E3C for ; Mon, 15 Mar 2004 09:11:22 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: calendula-devel@fudosys.com Date: Mon, 15 Mar 2004 09:11:25 -0500 Subject: Re: [Calendula-devel] construction plans to date Reply-To: bill-bell@bill-bell.hamilton.on.ca Message-ID: <4055733D.10728.132F2FC9@localhost> Priority: normal In-reply-to: <3152748.1079358718555.JavaMail.tpanzarella@mac.com> X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 15 Mar 2004 at 8:51, Thomas Panzarella wrote: > > I too can deal with Python. But I must say, that I am inclined to > think that a compiled language with strong typing would be preferred > for a project of this scope. (a) We can "compile" Python in various ways. The compiled codes are, of course, larger. However, that might not be an important factor for this project. (b) Python _is_ strongly typed. > Also, I think much more important that the ultimate language is the architecture. Perhaps we can agree that we will surely fail if we do a poor job of the architecture. I believe it might have been you that mentioned using UML. OK. An alternative would be literate programming, which is supported by Leo. This would have the advantage that it tends to be easier to exchange and modify texts than graphics. Or, maybe there's a free vehicle that supports UML; I'd love to know about one. > A well designed object model and the use of patterns will pay off many > times over in the end. Yes, I agree. At the same time, there are numerous ways of achieving that. > If the design is done right, we could code this in any language that > supports OO -- Sure. However, it's worth considering the fact that some languages in which we could code (and I'm thinking of C++) might cost us two or three times the work. Anyway, I was just letting others know what I can offer. It might be that my ego got in the way. Cheers, Bill From tpanzarella@mac.com Mon Mar 15 09:01:00 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 515346DDD; Mon, 15 Mar 2004 09:01:00 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-87.apple.com [17.250.248.87]) by riposte.org (Postfix) with ESMTP id 779D06DD4 for ; Mon, 15 Mar 2004 09:00:28 -0600 (CST) Received: from webmail18.mac.com (webmail18-en1 [10.13.10.160]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i2FF0RYx021715 for ; Mon, 15 Mar 2004 07:00:27 -0800 (PST) Received: from webmail18 (localhost [127.0.0.1]) by webmail18.mac.com (8.12.6/8.12.2) with ESMTP id i2FF0RCL022013 for ; Mon, 15 Mar 2004 07:00:27 -0800 (PST) Message-ID: <6045366.1079362827702.JavaMail.tpanzarella@mac.com> Date: Mon, 15 Mar 2004 10:00:27 -0500 From: Thomas Panzarella To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] construction plans to date X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On Monday, March 15, 2004, at 09:11AM, Bill Bell wrote: > >(b) Python _is_ strongly typed. > I disagree, but that's not the point of this discussion. What I will agree on is that "strong testing" of Python code can ultimately lead to the same end result of strong static type checking at compile time (ala C++, Java, etc.) ... of course just because code compiles doesn't mean it *works* ... strong testing is just as important in a C++ or Java environment as well. > >> Also, I think much more important that the ultimate language is the architecture. > >Perhaps we can agree that we will surely fail if we do a poor job of the architecture. > Agreed. > >I believe it might have been you that mentioned using UML. OK. > yep. > >An alternative would be literate programming, which is supported by Leo. This would >have the advantage that it tends to be easier to exchange and modify texts than >graphics. > Don't know about this ... send some links that we could check out... > >Or, maybe there's a free vehicle that supports UML; I'd love to know about >one. > http://www.gentleware.com/products/descriptions/ce.php4 > >> If the design is done right, we could code this in any language that >> supports OO -- > >Sure. However, it's worth considering the fact that some languages in which we could >code (and I'm thinking of C++) might cost us two or three times the work. > I was actually thinking Java. With the amount of freely available and open source development tools for Java today, I think Java developement can happen just as fast as using a scripting language like Perl or Python (YMMV). I also think that there are additional benefits to Java: 1- javadoc - API docs are just as important as code in an open source project and javadoc makes it painless 2- native look-and-feels via Swing - support for XP, Java, GTK+, and Aqua. Anyway, I absolutely don't want to debate over language preferences with anyone. I think we need to do our technical due diligence when designing this system taking into account the environment that the system will be running in (non-profits that can't afford off-the-shelf tools and could care less what the underlying technology is). I'm interested in helping non-profits, not debating the technical merits of Python vs. Java or whatever.... Also, I want it to be clear that I have nothing against Python. I enjoy programming in Python. If that is what Calendula is ultimately going to be implemented in, so be it. I was just throwing in another perspective / preference .... t. From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 10:27:10 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id E85426DDD; Mon, 15 Mar 2004 10:27:10 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id 48F1B6DD4 for ; Mon, 15 Mar 2004 10:26:38 -0600 (CST) Received: from default (Hamilton-ppp112770.sympatico.ca [216.209.142.145]) by smaug.vex.net (Postfix) with ESMTP id AAE9A259CD for ; Mon, 15 Mar 2004 11:26:35 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: calendula-devel@fudosys.com Date: Mon, 15 Mar 2004 11:26:40 -0500 Subject: Re: [Calendula-devel] construction plans to date Reply-To: bill-bell@bill-bell.hamilton.on.ca Message-ID: <405592F0.19943.13AB010B@localhost> Priority: normal In-reply-to: <6045366.1079362827702.JavaMail.tpanzarella@mac.com> X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 15 Mar 2004 at 10:00, Thomas Panzarella wrote: > > What I will agree on is that "strong testing" ... I seem to hear you alluding to the idea that language choice and testing strategy are interdependent. If so, I definitely agree, FWIW. We would need to discuss this further. In fact, we need statements about language choice and testing strategy. More generally, I haven't noticed any outline about software engineering for this project. Perhaps we should start one, so that, as far as possible, we discuss issues once, record decisions, then move on to issues that haven't been decided. > Don't know about [Leo] ... send some links that we could check out... http://webpages.charter.net/edreamleo/front.html ... which seems to provide a link to literate programming, as a bonus. I was amazed to see an idea as old as this re-emerge; still, it might help us. > >Or, maybe there's a free vehicle that supports UML; I'd love to know about > >one. > http://www.gentleware.com/products/descriptions/ce.php4 Thanks. Poseidon seems to be most closely associated with java, but then Leo favours Python work. Either looks interesting to me. Let's put this matter into an outline. Once we have enough items, let's priortise them, and finish discussions, so that we can move on. > Anyway, I absolutely don't want to debate over language preferences > with anyone. ...I'm interested in helping non-profits, not debating > the technical merits of Python vs. Java or whatever.... So you concede that Python is better???? Only joking! I don't care either. However, we need to start a process for taking decisions in order to make progress. Bill From creede@penguinsinthenight.com Mon Mar 15 11:58:21 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 7A9936DDD; Mon, 15 Mar 2004 11:58:20 -0600 (CST) Received: from igor.penguinsinthenight.com (c-24-18-220-54.client.comcast.net [24.18.220.54]) by riposte.org (Postfix) with ESMTP id 45C476DD4 for ; Mon, 15 Mar 2004 11:57:48 -0600 (CST) Received: by igor.penguinsinthenight.com (Postfix, from userid 1000) id 0F9B3216089; Mon, 15 Mar 2004 09:57:47 -0800 (PST) Date: Mon, 15 Mar 2004 09:57:46 -0800 From: Creede Lambard To: Bill Bell Cc: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] construction plans to date Message-ID: <20040315175746.GC24283@igor.penguinsinthenight.com> References: <3152748.1079358718555.JavaMail.tpanzarella@mac.com> <4055733D.10728.132F2FC9@localhost> In-Reply-To: <4055733D.10728.132F2FC9@localhost> X-Spook: /usr/local/bin/spook User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-11.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary=Pk6IbRAofICFmK5e Content-Disposition: inline Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: --Pk6IbRAofICFmK5e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 15, 2004 at 09:11:25AM -0500, Bill Bell wrote: > Sure. However, it's worth considering the fact that some languages in whi= ch > we could code (and I'm thinking of C++) might cost us two or three times > the work. > C++ will also probably cost you at least one potential developer. I'm just another Perl hacker who knows enough Python to get into trouble, and while I can probably trust myself to get up to speed on wxPython quickly enough to = do some code for Calendula, I make no such claims about C, C++ or Java. (Howev= er if Calendula were to go to one of these languages, even if I'm not coding, I know how to write documentation and the like.) Python might also make it easier for NPOs to do their own modifications to the code, since it's much easier to learn than lower-level languages. And on a slightly less serious note, Darryl is a card-carrying member of House Slytherin, and he has so far resisted my efforts to convert him back = to the Multiple True Ways of Perl, where I first met him. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * .~. ( : Creede Lambard : Never rush a miracle man. . / V \ . :------------------------: You get lousy miracles. /( )\ : creede at : --------------------------------^^-^^----: penguinsinthenight : =20 Linux. Reliable and free. Pick any two. : dot com : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Pk6IbRAofICFmK5e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAVe6a6RaRqmjNX/0RAoU6AJ9SCTLy/UY5wtd7Ot+uXWXrcPrTzgCfUzyU Zy4XTMo+uXrjPmMbboyeOgQ= =se7z -----END PGP SIGNATURE----- --Pk6IbRAofICFmK5e-- From maasj@dm.org Mon Mar 15 12:15:17 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id DA61B6DDD; Mon, 15 Mar 2004 12:15:17 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id 2B9086DD4 for ; Mon, 15 Mar 2004 12:14:45 -0600 (CST) Received: from noah.dm.org (noah.dm.org [216.169.168.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dm.org (Postfix) with ESMTP id 29BD0235202 for ; Mon, 15 Mar 2004 13:14:40 -0500 (EST) Date: Mon, 15 Mar 2004 13:14:39 -0500 (EST) From: Jason Maas To: calendula-devel@fudosys.com Message-ID: X-DiscipleMakers-MailScanner: Found to be clean X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Calendula-devel] GNUe analysis - might be helpful Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi all, I'm excited to see the traffic on this list increasing and things starting to roll! I have a thought for an exercise that could be very helpful for us. I think it might be wise to do some sort of analysis of the GNUe project (www.gnue.org). I think it would be helpful to understand their architecture and learn from their experience. If we're not going to join them then I think someone should write down why and what we want to do differently. That would help us avoid reinventing the wheel and probably be useful in the future as people stop in and ask how Calendula is differnt from GNUe. I'm just thinking of a simple one page writeup with some bullets and a summary. Does this sound useful? Anyone wanna give it a shot? Jason -- Jason Maas DiscipleMakers Systems Dept --> www.dm.org From darrylc@fudosys.com Mon Mar 15 13:10:25 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 0A21D6DD4 for ; Mon, 15 Mar 2004 13:10:25 -0600 (CST) From: Darryl Caldwell To: caldev In-Reply-To: <405592F0.19943.13AB010B@localhost> References: <405592F0.19943.13AB010B@localhost> Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079377605.1305.44.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Mar 2004 11:06:46 -0800 Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] plans plans plans Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hello all, Thanks for all of the input. I can hear nonprofits around the world breathing an unconscious sigh of relief.... Ok. The tasks at hand: 1. If you are interested in development, get an account on Savannah and let me know your account name. 2. Design docs. First, do the requirements (REQ) look good to everyone? Do we need to convert any of the existing items into standard UML? 3. Language: Python for flexibility, readability, and as my own safety net (meaning if you all get hit by a bus, I need to be able to forge ahead). wxPython has really good support for adopting a native look/feel, but this will come after the Zope prototype. -D On Mon, 2004-03-15 at 08:26, Bill Bell wrote: > On 15 Mar 2004 at 10:00, Thomas Panzarella wrote: > > > > What I will agree on is that "strong testing" .. > > I seem to hear you alluding to the idea that language choice and testing strategy are > interdependent. If so, I definitely agree, FWIW. We would need to discuss this > further. In fact, we need statements about language choice and testing strategy. > > More generally, I haven't noticed any outline about software engineering for this > project. Perhaps we should start one, so that, as far as possible, we discuss issues > once, record decisions, then move on to issues that haven't been decided. > > > Don't know about [Leo] ... send some links that we could check out... > > http://webpages.charter.net/edreamleo/front.html > > ... which seems to provide a link to literate programming, as a bonus. I was amazed > to see an idea as old as this re-emerge; still, it might help us. > > > >Or, maybe there's a free vehicle that supports UML; I'd love to know about > > >one. > > http://www.gentleware.com/products/descriptions/ce.php4 > > Thanks. Poseidon seems to be most closely associated with java, but then Leo > favours Python work. Either looks interesting to me. Let's put this matter into an > outline. Once we have enough items, let's priortise them, and finish discussions, so > that we can move on. > > > Anyway, I absolutely don't want to debate over language preferences > > with anyone. ...I'm interested in helping non-profits, not debating > > the technical merits of Python vs. Java or whatever.... > > So you concede that Python is better???? Only joking! > > I don't care either. However, we need to start a process for taking decisions in order > to make progress. > > Bill > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Mon Mar 15 13:42:45 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 192BD6DD4 for ; Mon, 15 Mar 2004 13:42:45 -0600 (CST) Subject: Re: [Calendula-devel] GNUe analysis - might be helpful From: Darryl Caldwell To: caldev Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079379527.1305.72.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Mar 2004 11:38:47 -0800 Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Analysis of GNUe framework... I am not sure that is a good idea, since I did spend a lot of time on it a while back. But I think we can do this right here and then someone can summarize. Why GNUe isn't good for Calendula: * Poor documentation (the current developers prefer IRC) * Unstable framework * Poor support (very little list traffic), limited adoption * inflexible UI design I used spent a couple of weeks downloading their IRC logs and grepping for the answers to my questions. I eventually decided that this is not a good foundation to build one's house upon. When I pointed this out to them they said, "well that's how we like to work." A better analysis would be to look at the GNUMED project (www.gnumed.org). On Mon, 2004-03-15 at 10:14, Jason Maas wrote: > Hi all, > > I'm excited to see the traffic on this list increasing and things starting > to roll! I have a thought for an exercise that could be very helpful for > us. > > I think it might be wise to do some sort of analysis of the GNUe project > (www.gnue.org). I think it would be helpful to understand their > architecture and learn from their experience. If we're not going to join > them then I think someone should write down why and what we want to do > differently. That would help us avoid reinventing the wheel and probably > be useful in the future as people stop in and ask how Calendula is > differnt from GNUe. > > I'm just thinking of a simple one page writeup with some bullets and a > summary. Does this sound useful? Anyone wanna give it a shot? > > Jason -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From tpanzarella@mac.com Mon Mar 15 14:24:43 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 2F0316DDD; Mon, 15 Mar 2004 14:24:43 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-45.apple.com [17.250.248.45]) by riposte.org (Postfix) with ESMTP id 557916DD4 for ; Mon, 15 Mar 2004 14:24:11 -0600 (CST) Received: from webmail07.mac.com (webmail07-en1 [10.13.11.149]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i2FKOAvx016074 for ; Mon, 15 Mar 2004 12:24:10 -0800 (PST) Received: from webmail07 (localhost [127.0.0.1]) by webmail07.mac.com (8.12.6/8.12.2) with ESMTP id i2FKOARE027101 for ; Mon, 15 Mar 2004 12:24:10 -0800 (PST) Message-ID: <11874033.1079382250561.JavaMail.tpanzarella@mac.com> Date: Mon, 15 Mar 2004 15:24:10 -0500 From: Thomas Panzarella To: caldev Subject: Re: [Calendula-devel] plans plans plans X-Spam-Status: No, hits=-5.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On Monday, March 15, 2004, at 02:06PM, Darryl Caldwell wrote: > >3. Language: Python for flexibility, readability, and as my own safety >net (meaning if you all get hit by a bus, I need to be able to forge >ahead). wxPython has really good support for adopting a native >look/feel, but this will come after the Zope prototype. > Good man Darryl. Just what we need, a "benevolent dictator". From maasj@dm.org Mon Mar 15 14:35:21 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id E20C86DDD; Mon, 15 Mar 2004 14:35:21 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id 3114A6DD4 for ; Mon, 15 Mar 2004 14:34:49 -0600 (CST) Received: from noah.dm.org (noah.dm.org [216.169.168.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dm.org (Postfix) with ESMTP id F292E23523F for ; Mon, 15 Mar 2004 15:34:46 -0500 (EST) Date: Mon, 15 Mar 2004 15:34:46 -0500 (EST) From: Jason Maas To: caldev Subject: Re: [Calendula-devel] GNUe analysis - might be helpful In-Reply-To: <1079379527.1305.72.camel@dhcppc4> Message-ID: References: <1079379527.1305.72.camel@dhcppc4> X-DiscipleMakers-MailScanner: Found to be clean X-MailScanner-From: maasj@dm.org X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi Darryl, On Mon, 15 Mar 2004, Darryl Caldwell wrote: >But I think we can do this right here and then someone can summarize. Great! I wasn't looking for anything real in-depth. >Why GNUe isn't good for Calendula: > >* Poor documentation (the current developers prefer IRC) >* Poor support (very little list traffic), limited adoption While those do raise red flags, I don't think they're show stoppers because they're fairly easily remedied. >* Unstable framework >* inflexible UI design These two are more interesting. Could you write a sentence or two about each one explaining what you mean? For example, by "unstable" do you mean that it crashes often or that the API changes daily...? >A better analysis would be to look at the GNUMED project >(www.gnumed.org). I poked around briefly on their website. I had never heard of the project before but it does look interesting. What in particular should we look at? Jason -- Jason Maas DiscipleMakers Systems Dept --> www.dm.org From tpanzarella@mac.com Mon Mar 15 14:38:16 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 2B5076DDD; Mon, 15 Mar 2004 14:38:16 -0600 (CST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by riposte.org (Postfix) with ESMTP id 5F9DF6DD4 for ; Mon, 15 Mar 2004 14:37:44 -0600 (CST) Received: from webmail07.mac.com (webmail07-en1 [10.13.11.149]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i2FKbhhB015475 for ; Mon, 15 Mar 2004 12:37:43 -0800 (PST) Received: from webmail07 (localhost [127.0.0.1]) by webmail07.mac.com (8.12.6/8.12.2) with ESMTP id i2FKbhRE027319 for ; Mon, 15 Mar 2004 12:37:43 -0800 (PST) Message-ID: <247821.1079383063139.JavaMail.tpanzarella@mac.com> Date: Mon, 15 Mar 2004 15:37:43 -0500 From: Thomas Panzarella To: caldev X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01 version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] Calendula PR at NTEN / Penguin Day Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: For those who are unaware, there is a mini conference being run in conjunction w/ NTEN in Philly at the end of the month called "Penguin Day" - http://www.penguinday.org. The point of it is to bring together open source developers and NGOs to start facilitating communication and the development of open source apps for NGOs. I have been asked by the organizers to facilitate a session at Penguin Day called "Emerging Technologies" / "Open Sourcing Java" -- my question is, do we want to "plug" Calendula there? If so, let's collaborate on what we would like to announce to the community at Penguin Day and I would be more than willing to be the mouth piece for us or to distribute literature, etc. t. From mako@yukidoke.org Mon Mar 15 15:06:30 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 8F0636DDD; Mon, 15 Mar 2004 15:06:30 -0600 (CST) Received: from micha.hampshire.edu (micha.hampshire.edu [192.101.188.235]) by riposte.org (Postfix) with ESMTP id 6E5316DD4 for ; Mon, 15 Mar 2004 15:05:53 -0600 (CST) Received: from micha ([127.0.0.1] helo=kamna ident=mako) by micha.hampshire.edu with esmtp (Exim 3.35 #1 (Debian)) id 1B2zHU-0008MJ-00 for ; Mon, 15 Mar 2004 16:05:53 -0500 Received: from mako by kamna with local (Exim 4.30) id 1B2zHS-0005vK-Jn for calendula-devel@fudosys.com; Mon, 15 Mar 2004 13:05:50 -0800 Date: Mon, 15 Mar 2004 22:05:50 +0100 From: "Benj. Mako Hill" To: caldev Subject: Re: [Calendula-devel] Calendula PR at NTEN / Penguin Day Message-ID: <20040315210550.GT20438@yukidoke.org> References: <247821.1079383063139.JavaMail.tpanzarella@mac.com> In-Reply-To: <247821.1079383063139.JavaMail.tpanzarella@mac.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Status: No, hits=-11.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="0rEjiS+nMGFQ7Kkj" Content-Disposition: inline Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: --0rEjiS+nMGFQ7Kkj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 15, 2004 at 03:37:43PM -0500, Thomas Panzarella wrote: > For those who are unaware, there is a mini conference being run in > conjunction w/ NTEN in Philly at the end of the month called > "Penguin Day" - http://www.penguinday.org. The point of it is to > bring together open source developers and NGOs to start facilitating > communication and the development of open source apps for NGOs. I > have been asked by the organizers to facilitate a session at Penguin > Day called "Emerging Technologies" / "Open Sourcing Java" -- my > question is, do we want to "plug" Calendula there? If so, let's > collaborate on what we would like to announce to the community at > Penguin Day and I would be more than willing to be the mouth piece > for us or to distribute literature, etc. I'll be there as well. --=20 Benjamin Mako Hill mako@debian.org http://mako.yukidoke.org/ --0rEjiS+nMGFQ7Kkj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAVhquic1LIWB1WeYRAnxYAKDpWBvz4uReAfVQDfyyh9zk76NvkwCglIld CRcju0N8bLTtzmMxoj+HLQc= =f2gt -----END PGP SIGNATURE----- --0rEjiS+nMGFQ7Kkj-- From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 15:08:26 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id AD5016DDE; Mon, 15 Mar 2004 15:08:26 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id 2C3D46DD4 for ; Mon, 15 Mar 2004 15:07:53 -0600 (CST) Received: from default (Hamilton-ppp112683.sympatico.ca [216.209.142.58]) by smaug.vex.net (Postfix) with ESMTP id 194812577E for ; Mon, 15 Mar 2004 16:07:51 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: calendula-devel@fudosys.com Date: Mon, 15 Mar 2004 16:07:56 -0500 Subject: Re: [Calendula-devel] plans plans plans Reply-To: bill-bell@bill-bell.hamilton.on.ca Message-ID: <4055D4DC.9896.14AC8400@localhost> Priority: normal In-reply-to: <1079377605.1305.44.camel@dhcppc4> References: <405592F0.19943.13AB010B@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 15 Mar 2004 at 11:06, Darryl Caldwell wrote, in part: > 2. Design docs. First, do the requirements (REQ) look good to everyone? Donors are often drawn by tax advantages and concessions. For example, in Canada about 75% of one's donation to a registered political party is refundable at income tax time. Donors might be more willing to cough up again if reminded of benefits they'd had before. Perhaps we should consider providing for information about each donor with to tax. Bill From bill-bell@bill-bell.hamilton.on.ca Mon Mar 15 15:12:41 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 856E56DDD; Mon, 15 Mar 2004 15:12:41 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id A3FFE6DD4 for ; Mon, 15 Mar 2004 15:12:09 -0600 (CST) Received: from default (Hamilton-ppp112683.sympatico.ca [216.209.142.58]) by smaug.vex.net (Postfix) with ESMTP id 91DEB25798 for ; Mon, 15 Mar 2004 16:12:07 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: calendula-devel@fudosys.com Date: Mon, 15 Mar 2004 16:12:13 -0500 Subject: Re: [Calendula-devel] plans plans plans Reply-To: bill-bell@bill-bell.hamilton.on.ca Message-ID: <4055D5DD.2665.14B06E2F@localhost> Priority: normal In-reply-to: <1079377605.1305.44.camel@dhcppc4> References: <405592F0.19943.13AB010B@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 15 Mar 2004 at 11:06, Darryl Caldwell wrote: > > 3. Language: Python for flexibility, readability, and as my own safety net > (meaning if you all get hit by a bus, I need to be able to forge ahead). > wxPython has really good support for adopting a native look/feel, but this > will come after the Zope prototype. Multi-client systems are harder to build than those that are for single clients. What's more, we are likely to spend considerable time fooling with the GUI, and it might be unwise to need to drag a server along with us--_especially_ Zope. (Lots of people never get over the learning curve for that beasty.) Why not build a single-client version of the system first? One immediate payoff would be that it could be distributed to quite small non-profits (who are, after all, principal targets for the system), which would benefit them and give us a lot of feedback about usability and the like. Bill From tpanzarella@mac.com Mon Mar 15 15:32:33 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id CCA416DDD; Mon, 15 Mar 2004 15:32:33 -0600 (CST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by riposte.org (Postfix) with ESMTP id 1BB316DD4 for ; Mon, 15 Mar 2004 15:32:01 -0600 (CST) Received: from webmail07.mac.com (webmail07-en1 [10.13.11.149]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i2FLW0NT007011 for ; Mon, 15 Mar 2004 13:32:00 -0800 (PST) Received: from webmail07 (localhost [127.0.0.1]) by webmail07.mac.com (8.12.6/8.12.2) with ESMTP id i2FLVxRE028263 for ; Mon, 15 Mar 2004 13:31:59 -0800 (PST) Message-ID: <10237726.1079386319840.JavaMail.tpanzarella@mac.com> Date: Mon, 15 Mar 2004 16:31:59 -0500 From: Thomas Panzarella To: caldev Subject: Re: [Calendula-devel] Calendula PR at NTEN / Penguin Day X-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On Monday, March 15, 2004, at 04:05PM, Benj. Mako Hill wrote: > >I'll be there as well. > Great. Let's meet up and chat. Also, if you are going to be in Philly on Sat night, there is an informal gathering called "Thirsty Penguins" the night before: http://www.dotorganics.org/~tpanzarella/blog/blosxom.cgi/2004/02/15#DrunkPenguins This is just a time to hang out, drink beer, and talk NGO open source. t. From darrylc@fudosys.com Mon Mar 15 17:37:23 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id AB1CA6DD4 for ; Mon, 15 Mar 2004 17:37:22 -0600 (CST) Subject: Re: [Calendula-devel] GNUe analysis - might be helpful From: Darryl Caldwell To: caldev In-Reply-To: References: <1079379527.1305.72.camel@dhcppc4> Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079393514.1289.35.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Mar 2004 15:31:54 -0800 Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 2004-03-15 at 12:34, Jason Maas wrote: > >Why GNUe isn't good for Calendula: > > > >* Poor documentation (the current developers prefer IRC) > >* Poor support (very little list traffic), limited adoption > > While those do raise red flags, I don't think they're show stoppers > because they're fairly easily remedied. They are show stoppers for me because it means that the development tools aren't mature enough to attract and sustain developers across a broad spectrum. > > >* Unstable framework > >* inflexible UI design > > These two are more interesting. Could you write a sentence or two about > each one explaining what you mean? For example, by "unstable" do you mean > that it crashes often or that the API changes daily...? > GNUe Designer crashed every time. The UI for GNUe Forms is pretty much set in stone. While it is nice to be able to whip up some xml and not have to worry about developing a whole app from the ground up, I'd rather control the look/feel decisions. > >A better analysis would be to look at the GNUMED project > >(www.gnumed.org). > > I poked around briefly on their website. I had never heard of the project > before but it does look interesting. What in particular should we look > at? * wxPython toolkit. * Client/Server model * Modular design * The database abstraction is similar to what you guys at DM have expressed an interest in. * Useful Design docs. * The UI offers a Python shell for interfacing with the guts of the system. -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Mon Mar 15 18:31:38 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id B74036DD4; Mon, 15 Mar 2004 18:31:36 -0600 (CST) From: Darryl Caldwell To: bill-bell@bill-bell.hamilton.on.ca Cc: caldev In-Reply-To: <4055D5DD.2665.14B06E2F@localhost> References: <405592F0.19943.13AB010B@localhost> <4055D5DD.2665.14B06E2F@localhost> Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079396730.1288.58.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Mar 2004 16:25:31 -0800 Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] multiple clients Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Bill, I have had a client/server model in mind from the beginning. I envision this system going into an office of 8 desktops. Not everyone will use Calendula except one or two financial development officers and other staff doing data entry. Zope is the easiest thing I have ever installed and it has some built in user admin that will come in handy. I am not expecting nonprofit personnel to learn dtml or Zope Page Templates. After looking at the cool code you have written for upload PDFs into Zope for text searches in ZCatalogs, I am not worried about you. In regard to multiple clients, the dm.org guys have some good ideas using the Modeling framework. http://modeling.sourceforge.net/ And lastly, I am hopeful that a demo version of Morphix/Debian-NP loaded up with Calendula and supporting systems would fit the bill, Bill. -D On Mon, 2004-03-15 at 13:12, Bill Bell wrote: > On 15 Mar 2004 at 11:06, Darryl Caldwell wrote: > > > > 3. Language: Python for flexibility, readability, and as my own safety net > > (meaning if you all get hit by a bus, I need to be able to forge ahead). > > wxPython has really good support for adopting a native look/feel, but this > > will come after the Zope prototype. > > Multi-client systems are harder to build than those that are for single clients. What's > more, we are likely to spend considerable time fooling with the GUI, and it might be > unwise to need to drag a server along with us--_especially_ Zope. (Lots of people > never get over the learning curve for that beasty.) > > Why not build a single-client version of the system first? One immediate payoff would > be that it could be distributed to quite small non-profits (who are, after all, principal > targets for the system), which would benefit them and give us a lot of feedback about > usability and the like. > > Bill > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From tpanzarella@mac.com Mon Mar 15 19:19:25 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 96E7A6DDC; Mon, 15 Mar 2004 19:19:25 -0600 (CST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by riposte.org (Postfix) with ESMTP id DF37A6DD4 for ; Mon, 15 Mar 2004 19:18:53 -0600 (CST) Received: from webmail30-en1.mac.com (webmail30-en1 [10.13.10.130]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i2G1IrhB011555 for ; Mon, 15 Mar 2004 17:18:53 -0800 (PST) Received: from webmail30 (localhost.mac.com [127.0.0.1]) by webmail30-en1.mac.com (8.12.6/8.12.6) with ESMTP id i2G1IrWS008249 for ; Mon, 15 Mar 2004 17:18:53 -0800 (PST) Message-ID: <10053998.1079399933365.JavaMail.tpanzarella@mac.com> Date: Mon, 15 Mar 2004 20:18:53 -0500 From: Thomas Panzarella To: caldev Subject: Re: [Calendula-devel] multiple clients X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01 version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Once again, I am confused, sorry. (see below) > >I have had a client/server model in mind from the beginning. I envision >this system going into an office of 8 desktops. Not everyone will use >Calendula except one or two financial development officers and other >staff doing data entry. > >Zope is the easiest thing I have ever installed and it has some built in >user admin that will come in handy. I am not expecting nonprofit >personnel to learn dtml or Zope Page Templates. After looking at the >cool code you have written for upload PDFs into Zope for text searches >in ZCatalogs, I am not worried about you. > I have only minimal exposure to Zope, but does it support something other than HTTP? If not, why would we write a full blown (presumably) multi-threaded client that cannot maintain a persistent connection to the server? In this case, the desktop GUI seems pointless, dynamically rendered web pages would fit the bill just fine. > >In regard to multiple clients, the dm.org guys have some good ideas >using the Modeling framework. > >http://modeling.sourceforge.net/ > What does object / relational mapping have to do with clients? Object / relational mapping is a persistence tier issue and should be designed completely independent of any client code. Am I missing something? From darrylc@fudosys.com Tue Mar 16 12:57:33 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id DD0BA6DD4 for ; Tue, 16 Mar 2004 12:57:32 -0600 (CST) From: Darryl Caldwell To: caldev Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079463060.1293.20.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Mar 2004 10:51:00 -0800 Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] Article Cleaned Up Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: I just spent a lot of time editing and cleaning up the business case article at http://fudosys.com/Calendula.html Use this one if you are printing copies to send to NPO peers.... -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From tpanzarella@mac.com Tue Mar 16 13:03:29 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id C28516DDD; Tue, 16 Mar 2004 13:03:29 -0600 (CST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by riposte.org (Postfix) with ESMTP id EE1076DD4 for ; Tue, 16 Mar 2004 13:02:56 -0600 (CST) Received: from webmail18.mac.com (webmail18-en1 [10.13.10.160]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i2GJ2tiv003036 for ; Tue, 16 Mar 2004 11:02:55 -0800 (PST) Received: from webmail18 (localhost [127.0.0.1]) by webmail18.mac.com (8.12.6/8.12.2) with ESMTP id i2GJ2tCL025247 for ; Tue, 16 Mar 2004 11:02:55 -0800 (PST) Message-ID: <11835203.1079463775545.JavaMail.tpanzarella@mac.com> Date: Tue, 16 Mar 2004 14:02:55 -0500 From: Thomas Panzarella To: caldev Subject: Re: [Calendula-devel] Article Cleaned Up X-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Is this the latest version in CVS? On Tuesday, March 16, 2004, at 01:51PM, Darryl Caldwell wrote: >I just spent a lot of time editing and cleaning up the business case >article at http://fudosys.com/Calendula.html Use this one if you are >printing copies to send to NPO peers.... > >-D > > >-- >Darryl Caldwell darrylc@fudosys.com >Fudo Systems www.fudosys.com >206/567-5802 "Free Your Computers!" > >_______________________________________________ >Calendula-devel mailing list >Calendula-devel@fudosys.com >http://list.fudosys.com/mailman/listinfo/calendula-devel > > From darrylc@fudosys.com Tue Mar 16 13:12:20 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 2EF076DDC for ; Tue, 16 Mar 2004 13:12:20 -0600 (CST) Subject: Re: [Calendula-devel] Article Cleaned Up From: Darryl Caldwell To: caldev In-Reply-To: <11835203.1079463775545.JavaMail.tpanzarella@mac.com> References: <11835203.1079463775545.JavaMail.tpanzarella@mac.com> Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079463937.1292.26.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Mar 2004 11:05:38 -0800 Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: This version is not in cvs yet. I am actually having a problem connecting to savannah from my corner of the world. Can any of you even get to the web site? -D On Tue, 2004-03-16 at 11:02, Thomas Panzarella wrote: > Is this the latest version in CVS? > > On Tuesday, March 16, 2004, at 01:51PM, Darryl Caldwell wrote: > > >I just spent a lot of time editing and cleaning up the business case > >article at http://fudosys.com/Calendula.html Use this one if you are > >printing copies to send to NPO peers.... > > > >-D > > > > > >-- > >Darryl Caldwell darrylc@fudosys.com > >Fudo Systems www.fudosys.com > >206/567-5802 "Free Your Computers!" > > > >_______________________________________________ > >Calendula-devel mailing list > >Calendula-devel@fudosys.com > >http://list.fudosys.com/mailman/listinfo/calendula-devel > > > > > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Tue Mar 16 15:07:42 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 20D2F6DD4 for ; Tue, 16 Mar 2004 15:07:42 -0600 (CST) Subject: Re: [Calendula-devel] multiple clients From: Darryl Caldwell To: caldev In-Reply-To: <10053998.1079399933365.JavaMail.tpanzarella@mac.com> References: <10053998.1079399933365.JavaMail.tpanzarella@mac.com> Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079470791.1293.76.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Mar 2004 12:59:51 -0800 Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi, Benevolent Dictator here. Sorry, I was trying to do too many things at once yesterday (and today). Let's set the mulitple client discussion aside for now. I want to keep this first round of Calendula development very simple. Until a working prototype (even a mediocre one) is out for all to see, this project is not get the attention it deserves. To wit, I will be polling you all for an inventory of your talents. I will be making requests of you coders for specific tasks. Baby steps..... -D On Mon, 2004-03-15 at 17:18, Thomas Panzarella wrote: > Once again, I am confused, sorry. (see below) > > > > >I have had a client/server model in mind from the beginning. I envision > >this system going into an office of 8 desktops. Not everyone will use > >Calendula except one or two financial development officers and other > >staff doing data entry. > > > >Zope is the easiest thing I have ever installed and it has some built in > >user admin that will come in handy. I am not expecting nonprofit > >personnel to learn dtml or Zope Page Templates. After looking at the > >cool code you have written for upload PDFs into Zope for text searches > >in ZCatalogs, I am not worried about you. > > > > I have only minimal exposure to Zope, but does it support something other than HTTP? If not, why would we write a full blown (presumably) multi-threaded client that cannot maintain a persistent connection to the server? In this case, the desktop GUI seems pointless, dynamically rendered web pages would fit the bill just fine. > > > > >In regard to multiple clients, the dm.org guys have some good ideas > >using the Modeling framework. > > > >http://modeling.sourceforge.net/ > > > > What does object / relational mapping have to do with clients? Object / relational mapping is a persistence tier issue and should be designed completely independent of any client code. Am I missing something? > > > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Wed Mar 17 12:49:21 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 163F36DDD for ; Wed, 17 Mar 2004 12:49:21 -0600 (CST) From: Darryl Caldwell To: caldev Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079548708.1309.1.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 17 Mar 2004 10:38:28 -0800 Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] Savannah Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Heads up. Savannah is down. No word yet on why. -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From jamest@gnuenterprise.org Wed Mar 17 16:23:17 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 062D26DDD; Wed, 17 Mar 2004 16:23:17 -0600 (CST) Received: from newton.math.ksu.edu (gw.math.ksu.edu [129.130.6.1]) by riposte.org (Postfix) with ESMTP id 2E1EE6DD4 for ; Wed, 17 Mar 2004 16:22:44 -0600 (CST) Received: from hobbes.math.ksu.edu (HOBBES.MATH.KSU.EDU [172.16.2.24]) by newton.math.ksu.edu (Postfix) with ESMTP id 970F3D6C3B for ; Wed, 17 Mar 2004 16:22:43 -0600 (CST) From: James Thompson To: calendula-devel@fudosys.com Date: Wed, 17 Mar 2004 16:22:38 -0600 User-Agent: KMail/1.6.1 Message-Id: <200403171622.38896.jamest@gnuenterprise.org> X-Spam-Status: No, hits=-5.2 required=5.0 tests=BAYES_10,USER_AGENT_KMAIL version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Calendula-devel] re: GNUe analysis - might be helpful Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Someone pointed out to me the mail below. So I figured I'd join and respond.... > Why GNUe isn't good for Calendula: > > * Poor documentation This is true. It's worse than I recall it being. I'll try and address that. > * Unstable framework I'm not sure which part of GNUe is being referred to here. I'm using gnue-common based apps 24/7 in local company that does business almost nationwide. They use gnue-forms based UIs daily to accomplish tasks, such as routing their incoming faxes (billings) to the appropriate customer accounts. > * Poor support (very little list traffic), We have gravitated toward IRC based support. This did make for poor list support. On the other hand if you catch a developer in IRC you can frequently get patches in minutes working in real time with the developers. > limited adoption This partially falls back on poor documentation. But any project, such as your own, will also have limited adoption at first. > * inflexible UI design I think this is where some of the confusion from the docs is hurting GNUe. All the gnue tools can be used separately. When using parts of GNUe you are not forced into things like using GNUe-Forms as your UI. GNUe-POS (available in our svn tree) is based upon gnue-common and wxPython. I'm currently building a web based project using mod_python, gnue-common, gnue-reports, etc. I may or may not add gnue-forms based administration forms. It's basically just another set of tools in your toolbox. > > them they said, "well that's how we like to work." > This may indeed be what you were told. If so then I'll apologize and try to explain a little. We constantly have people people drop by IRC telling us how we're doing things wrong. We've had people suggest we throw out 10s of thousands of lines of code to do things their way. Most the time they won't bother to learn our systems before doing so. Often times these same people are the ones that will never contribute anything. We've had people come in then quickly fork after telling us we're too slow. I don't think any single fork has ever survived. I think they tend to figure out that some of this stuff can't be written fast. And it's hard to find people willing to write business apps for free in their spare time. Anyway, after a while you tend to get a little touchy when people start to question the hows and whys. Call it burn out, apathy, whatever you'd like. I know it's not right, but we're all human. I'm not meaning to say that Darryl said anything wrong. It's probably more like he caught that grumpy old man GNUe in a bad mood. :) So, is GNUe right for your project. I really can't say as I don't know much about it. Savannah web seems to be down. IMHO though, using gnue common alone would save a project an amazing amount of development work. But I'm a little bias about that :) If you have any questions please feel free to ask me. I'll do what I can to answer them. Take Care, James From darrylc@fudosys.com Wed Mar 17 17:29:48 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 8F65D6DD4; Wed, 17 Mar 2004 17:29:47 -0600 (CST) Subject: Re: [Calendula-devel] re: GNUe analysis - might be helpful From: Darryl Caldwell To: James Thompson Cc: caldev In-Reply-To: <200403171622.38896.jamest@gnuenterprise.org> References: <200403171622.38896.jamest@gnuenterprise.org> Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079566110.1278.51.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 17 Mar 2004 15:28:31 -0800 Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi James, I've been giving GNUe a hard time over on the gnue list these last few days. Thanks for coming to my house. (I've actually been playing with GNUe Designer these last 2 days, since Savannah has been down. I did follow your suggestion and install GNUe-Reports and now the wizard in Designer is working as expected.) I spent 2 weeks with 0.4.2 last year. You have come a long, long way since then. In my mind it is still questionable whether GNUe is right for Calendula. I really don't have time to experiment and hope it works out. I need to scratch my own itch and I need evidence of stability. You have said that GNUe is run under a needs-based development model and a IRC-based support model. So are many projects; but I venture that they all developed good foundations and communities because there was documentation early on. Look at Remi Delon's CherryPy (www.cherrypy.org). I don't want to rely on IRC for your support anymore than I want to rely on RedHat/SuSE/Mandrake for phone support. Email leaves a better audit trail, and a better basis for FAQs later on. If you want wider adoption, I suggest that one or all of the core GNUe developers stop writing apps for use in production (as you note below) and make documentation a priority. Every once in a while a GNUe developer will pop up on a list I am on, and will say, "Hey, why don't you use GNUe for your project?" I always complain about the lack of docs and visible signs of use. Show me, don't tell me. Less outreach, more support, please. Write some short guides, howtos, updated API docs, etc. You wrote a great email yesterday describing 4 quick steps to testing Designer. That was wonderful. Now write something describing how you created the apps you mentioned below. Other folks on the gnue list have supported my sentiments. I do really dig the concepts around GNUe. If I don't use it for Calendula, I can foresee using it for something else down the road. Thank you, thank you taking the time to join this list and for all of your support on your gnue list. You can find out more about Calendula at http://fudosys.com/Calendula.html. -Darryl ps> Did I mention that you should write more documentation? -D On Wed, 2004-03-17 at 14:22, James Thompson wrote: > Someone pointed out to me the mail below. So I figured I'd join and > respond.... > > > Why GNUe isn't good for Calendula: > > > > * Poor documentation > > This is true. It's worse than I recall it being. I'll try and address that. > > > * Unstable framework > > I'm not sure which part of GNUe is being referred to here. I'm using > gnue-common based apps 24/7 in local company that does business almost > nationwide. They use gnue-forms based UIs daily to accomplish tasks, such as > routing their incoming faxes (billings) to the appropriate customer accounts. > > > * Poor support (very little list traffic), > > We have gravitated toward IRC based support. This did make for poor list > support. On the other hand if you catch a developer in IRC you can > frequently get patches in minutes working in real time with the developers. > > > limited adoption > > This partially falls back on poor documentation. But any project, such as > your own, will also have limited adoption at first. > > > * inflexible UI design > > I think this is where some of the confusion from the docs is hurting GNUe. > All the gnue tools can be used separately. When using parts of GNUe you are > not forced into things like using GNUe-Forms as your UI. GNUe-POS (available > in our svn tree) is based upon gnue-common and wxPython. I'm currently > building a web based project using mod_python, gnue-common, gnue-reports, > etc. I may or may not add gnue-forms based administration forms. It's > basically just another set of tools in your toolbox. > > > > > them they said, "well that's how we like to work." > > > > This may indeed be what you were told. If so then I'll apologize and try to > explain a little. We constantly have people people drop by IRC telling us > how we're doing things wrong. We've had people suggest we throw out 10s of > thousands of lines of code to do things their way. Most the time they won't > bother to learn our systems before doing so. Often times these same people > are the ones that will never contribute anything. We've had people come in > then quickly fork after telling us we're too slow. I don't think any single > fork has ever survived. I think they tend to figure out that some of this > stuff can't be written fast. And it's hard to find people willing to write > business apps for free in their spare time. > > Anyway, after a while you tend to get a little touchy when people start to > question the hows and whys. Call it burn out, apathy, whatever you'd like. I > know it's not right, but we're all human. I'm not meaning to say that Darryl > said anything wrong. It's probably more like he caught that grumpy old man > GNUe in a bad mood. :) > > So, is GNUe right for your project. I really can't say as I don't know much > about it. Savannah web seems to be down. IMHO though, using gnue common > alone would save a project an amazing amount of development work. But I'm a > little bias about that :) > > If you have any questions please feel free to ask me. I'll do what I can to > answer them. > > Take Care, > James > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From jamest@gnuenterprise.org Thu Mar 18 16:05:15 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 929636DDD; Thu, 18 Mar 2004 16:05:15 -0600 (CST) Received: from newton.math.ksu.edu (gw.math.ksu.edu [129.130.6.1]) by riposte.org (Postfix) with ESMTP id BBBDD6DD4 for ; Thu, 18 Mar 2004 16:04:43 -0600 (CST) Received: from hobbes.math.ksu.edu (HOBBES.MATH.KSU.EDU [172.16.2.24]) by newton.math.ksu.edu (Postfix) with ESMTP id 11606D6C8F for ; Thu, 18 Mar 2004 16:04:43 -0600 (CST) From: James Thompson To: calendula-devel@fudosys.com Subject: Fwd: Re: [Calendula-devel] re: GNUe analysis - might be helpful Date: Thu, 18 Mar 2004 16:04:38 -0600 User-Agent: KMail/1.6.1 Message-Id: <200403181604.38801.jamest@gnuenterprise.org> X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MONEY_MAKING,QUOTED_EMAIL_TEXT,USER_AGENT_KMAIL version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+280555_9889177954383_63240525731" Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: --MIMEStream=_0+280555_9889177954383_63240525731 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I accidentally forgot to CC the list on this message this AM. --MIMEStream=_0+280555_9889177954383_63240525731 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Description: James Thompson : Re: [Calendula-devel] re: GNUe analysis - might be helpfu From: James Thompson To: Darryl Caldwell Subject: Re: [Calendula-devel] re: GNUe analysis - might be helpful Date: Thu, 18 Mar 2004 11:19:04 -0600 User-Agent: KMail/1.6.1 References: <200403171622.38896.jamest@gnuenterprise.org> <1079566110.1278.51.camel@dhcppc4> In-Reply-To: <1079566110.1278.51.camel@dhcppc4> Message-Id: <200403181119.04423.jamest@gnuenterprise.org> X-UID: 131 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline > I've been giving GNUe a hard time over on the gnue list these last few > days. Thanks for coming to my house. Ooooo, sorry about the mud on the carpet. > I spent 2 weeks with 0.4.2 last year. You have come a long, long way > since then. In my mind it is still questionable whether GNUe is right > for Calendula. I really don't have time to experiment and hope it works > out. I need to scratch my own itch and I need evidence of stability. You I understand the itch thing. However on the stability front I'd like to point out that gnue is in use in real world, money making situations. Specific parts of gnue are tested daily and people are paying for gnue based solutions that work. If you are thinking of creating a solution written completely from scratch then it is quite possible the initial code would be less stable than what another project (GNUe or something else) would provide. > I don't want to rely on IRC for your support anymore than I want to rely > on RedHat/SuSE/Mandrake for phone support. Email leaves a better audit > trail, and a better basis for FAQs later on. We are going to try and be more responsive to email support as the traffic the last few days have show people are interested. > If you want wider adoption, I suggest that one or all of the core GNUe > developers stop writing apps for use in production (as you note below) > and make documentation a priority. It's so easy to say this. Its so much harder in real life. Most if not all the developers are working on gnue features based upon needs. Those needs usually relate to either deadlines and work or money from a client. I know in my case a client doesn't care if X is fully documented, they only want X working, yesterday. That being said, i did reread our documentation (i typically don't have to :) and see it is hideously outdated and incomplete. I have shifted more of my time towards proper documenation and will be posting a least the start of something to our list later today. > tell me. Less outreach, more support, please. Write some short guides, > howtos, updated API docs, etc. You wrote a great email yesterday > describing 4 quick steps to testing Designer. That was wonderful. Now In progress. If fact, late last year we started adding epydoc comments to all our applications to cover the API front. They are far from complete but you can see the starting samples at http://www.gnuenterprise.org/~jamest/apis/ Again its partially a communications issue on our part. The developers know this is in progress but it hasn't been well communicated to the list. > > Thank you, thank you taking the time to join this list and for all of > your support on your gnue list. No problem. The list activity at gnue has been a bit of a wake up call for me. When GNUe was founded it was never my intention for things to become as closed as they have. I plan to take the steps needed to show we're not a dead project as many believe >You can find out more about Calendula at http://fudosys.com/Calendula.html. Like I have time to read web sites. I've got docs to write! j/k I'll check it out this weekend =) Take Care, James --MIMEStream=_0+280555_9889177954383_63240525731-- From pattonm@dm.org Thu Mar 18 16:43:46 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id C9DD06DD4; Thu, 18 Mar 2004 16:43:46 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id A8C526DDC for ; Thu, 18 Mar 2004 16:43:13 -0600 (CST) Received: by mail.dm.org (Postfix, from userid 510) id 15FAAC0609; Thu, 18 Mar 2004 17:43:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.dm.org (Postfix) with ESMTP id D5A0F164B28 for ; Thu, 18 Mar 2004 17:43:12 -0500 (EST) Date: Thu, 18 Mar 2004 17:43:12 -0500 (EST) From: Matthew Patton To: calendula-devel@fudosys.com Message-ID: X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Calendula-devel] DiscipleMakers weigh-in Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: 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 From darrylc@fudosys.com Fri Mar 19 16:45:17 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 5C58F6DDE for ; Fri, 19 Mar 2004 16:45:17 -0600 (CST) From: Darryl Caldwell To: caldev Content-Type: text/plain Organization: Fudo Systems Message-Id: <1079735927.1456.6.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 19 Mar 2004 14:38:48 -0800 Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] Savannah Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi, savannah.gnu.org is back in business. I added the workflow diagram and updated the article to the latest version. http://savannah.gnu.org/projects/calendula -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From darrylc@fudosys.com Sat Mar 20 17:52:37 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from www.fudosys.com (localhost.localdomain [127.0.0.1]) by riposte.org (Postfix) with SMTP id EB6726DD4; Sat, 20 Mar 2004 17:52:36 -0600 (CST) Received: from 64.38.163.26 (SquirrelMail authenticated user darrylc@fudosys.com) by webmail.fudosys.com with HTTP; Sat, 20 Mar 2004 15:52:37 -0800 (PST) Message-ID: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> In-Reply-To: References: Date: Sat, 20 Mar 2004 15:52:37 -0800 (PST) Subject: Re: [Calendula-devel] DiscipleMakers weigh-in From: "Darryl Caldwell" To: "Matthew Patton" Cc: calendula-devel@fudosys.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: > 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 for the overview, Matt. Could you by chance provide us with a simple use case for this receipting system. I am trying to visualize how this would fit into a CRM. -D -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From elwell642@hotmail.com Sat Mar 20 19:41:19 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 172886DDE; Sat, 20 Mar 2004 19:41:19 -0600 (CST) Received: from hotmail.com (bay2-f117.bay2.hotmail.com [65.54.247.117]) by riposte.org (Postfix) with ESMTP id 491A66DD4 for ; Sat, 20 Mar 2004 19:40:46 -0600 (CST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Mar 2004 17:40:42 -0800 Received: from 69.162.30.188 by by2fd.bay2.hotmail.msn.com with HTTP; Sun, 21 Mar 2004 01:40:42 GMT X-Originating-IP: [69.162.30.188] X-Originating-Email: [elwell642@hotmail.com] X-Sender: elwell642@hotmail.com From: "Tom Hallman" To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] DiscipleMakers weigh-in Date: Sat, 20 Mar 2004 20:40:42 -0500 Message-ID: X-OriginalArrivalTime: 21 Mar 2004 01:40:42.0302 (UTC) FILETIME=[857C1DE0:01C40EE5] X-Spam-Status: No, hits=-0.3 required=5.0 tests=BAYES_30,FROM_ENDS_IN_NUMS version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; format=flowed Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Darryl, >Thanks for the overview, Matt. Could you by chance provide >us with a simple use case for this receipting system. I am trying to >visualize how this would fit into a CRM. Currently, most staff workers in DiscipleMakers have some form of CRM (often Goldmine) to manage their donors, but a record of each donor's gift must be looked up separately (Excel/OpenOffice spreadsheet, etc.) This is a silly distinction, since both the CRM and "donor list" are using the same conceptual entities. Let's say that Matt Patton is supported financially by Jim Smith. A very useful feature for Matt would be to be able to pull up Jim's record (containing his name, his wife's name, their address, notes from their last meeting together, etc.) right alongside a list of all the financial gifts that Jim has given (including dates and amounts.) This last information would have been entered via the receipting system in the Headquarters. I hope this is helpful! ~Tom _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page – FREE download! http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/ From bill-bell@bill-bell.hamilton.on.ca Sun Mar 21 07:14:57 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 160C46DDE; Sun, 21 Mar 2004 07:14:57 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id 5829B6DD4 for ; Sun, 21 Mar 2004 07:14:24 -0600 (CST) Received: from default (Hamilton-ppp67798.sympatico.ca [216.208.50.131]) by smaug.vex.net (Postfix) with ESMTP id 73F86254D0 for ; Sun, 21 Mar 2004 08:14:07 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: calendula-devel@fudosys.com Date: Sun, 21 Mar 2004 08:13:43 -0500 Subject: Re: [Calendula-devel] DiscipleMakers weigh-in Reply-To: bill-bell@bill-bell.hamilton.on.ca Message-ID: <405D4EB7.4244.31E16F89@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 20 Mar 2004 at 20:40, Tom Hallman wrote, in part: > Currently, most staff workers in DiscipleMakers have some form of CRM > (often Goldmine) to manage their donors ... Would it be possible for you to indicate which Goldmine features are the most heavily used? > I hope this is helpful! Well _I_ find it interesting. Thanks! Bill From maasj@dm.org Sun Mar 21 19:33:08 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 0BD8E6DDE; Sun, 21 Mar 2004 19:33:08 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id 034A06DD4 for ; Sun, 21 Mar 2004 19:32:35 -0600 (CST) Received: from gondor.maasj.dm.org (gondor.maasj.dm.org [192.168.11.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dm.org (Postfix) with ESMTP id 1E69E2351F9 for ; Sun, 21 Mar 2004 20:32:25 -0500 (EST) Date: Sun, 21 Mar 2004 20:32:22 -0500 (EST) From: Jason Maas To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> Message-ID: References: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> X-DiscipleMakers-MailScanner: Found to be clean X-MailScanner-From: maasj@dm.org X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi Darryl, On Sat, 20 Mar 2004, Darryl Caldwell wrote: >Thanks for the overview, Matt. Could you by chance provide us with a >simple use case for this receipting system. I am trying to visualize how >this would fit into a CRM. I'll throw in a little more to try and clarify things. By "receipting" what we mean is the software that our secretaries use to handle contributions (donations) that come to our headquarters, usually in the form of checks. They use the software to enter in who the gift was from, who it's for, and then print a receipt to mail to the donor (hence the name "receipting"). It would be great for this "receipting" system to tie into our CRM software so all of our staff (most are remote) would automatically see all the gifts a contact has given when they look up a person's record in the CRM software. The basic idea we have is to have this big database of people that all of our software ties into, instead of our current situation of separate software for the donations, CRM, event/conference management, etc. I hope that makes sense. -Jason From darrylc@fudosys.com Sun Mar 21 22:25:23 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from www.fudosys.com (localhost.localdomain [127.0.0.1]) by riposte.org (Postfix) with SMTP id 62DB86DD4 for ; Sun, 21 Mar 2004 22:25:23 -0600 (CST) Received: from 64.38.161.33 (SquirrelMail authenticated user darrylc@fudosys.com) by webmail.fudosys.com with HTTP; Sun, 21 Mar 2004 20:25:23 -0800 (PST) Message-ID: <37741.64.38.161.33.1079929523.squirrel@webmail.fudosys.com> In-Reply-To: References: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> Date: Sun, 21 Mar 2004 20:25:23 -0800 (PST) Subject: Re: [Calendula-devel] DiscipleMakers weigh-in From: "Darryl Caldwell" To: calendula-devel@fudosys.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Thanks Jason and Tom, The use case you outlined is right in line with the REQ doc that I have written for Calendula. Many donors hang on to "thank-you" letters from charities and other NPOs for their tax records. You all can view the REQ in the CVS repository or send me a note and I will attach it to an email message to you. NOW would be a good time to read through the REQ to see if it is missing something obvious. It also contains good talking points for you consultants out there that deal with nonprofits on a regular basis, and especially all of you on your way to NTEN/Penguinday. -D > Hi Darryl, > > On Sat, 20 Mar 2004, Darryl Caldwell wrote: > >>Thanks for the overview, Matt. Could you by chance provide us with a >>simple use case for this receipting system. I am trying to visualize how >>this would fit into a CRM. > > I'll throw in a little more to try and clarify things. By "receipting" > what we mean is the software that our secretaries use to handle > contributions (donations) that come to our headquarters, usually in the > form of checks. They use the software to enter in who the gift was from, > who it's for, and then print a receipt to mail to the donor (hence > the name "receipting"). It would be great for this "receipting" system to > tie into our CRM software so all of our staff (most are remote) would > automatically see all the gifts a contact has given when they look up a > person's record in the CRM software. > > The basic idea we have is to have this big database of people that all of > our software ties into, instead of our current situation of separate > software for the donations, CRM, event/conference management, etc. > > I hope that makes sense. > > -Jason > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel > -- Darryl Caldwell darrylc@fudosys.com www.fudosys.com From pattonm@dm.org Tue Mar 23 09:12:13 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 336F36DDD; Tue, 23 Mar 2004 09:12:13 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id 437F46DDC; Tue, 23 Mar 2004 09:11:40 -0600 (CST) Received: by mail.dm.org (Postfix, from userid 510) id 590CBC0604; Tue, 23 Mar 2004 10:11:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.dm.org (Postfix) with ESMTP id 57960164B28; Tue, 23 Mar 2004 10:11:39 -0500 (EST) Date: Tue, 23 Mar 2004 10:11:39 -0500 (EST) From: Matthew Patton To: Darryl Caldwell Cc: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: <37741.64.38.161.33.1079929523.squirrel@webmail.fudosys.com> Message-ID: References: <37413.64.38.163.26.1079826757.squirrel@webmail.fudosys.com> <37741.64.38.161.33.1079929523.squirrel@webmail.fudosys.com> X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi Darryl, You asked that we view the REQ document in the CVS repository. I've done that and compared it with the requirements document we have here at DM for our receipting system. The following are things that you didn't have that we will need: Functionality ============= -There will be remote users whose user account will be associated with a certain fund (in our case, remote staff who each have a fund that their supporters give to). These users will need to be able to view certain reports: a. View gifts for their respective funds b. View a donor's contact information c. View an account's giving history (for what an account is, see "Data" below) d. Eventually it will be necessary to have the data that these remote users have about their donors (contact information, personal notes, relationship history) sync'd up with this central DB that stores the gifts that come in, but this is an advanced feature that can wait -The main kind of user, however, will be the administrator. In addition to the functionality you mention, the system will need to provide the admin with the following functionality: Deposits (see below under "Data" what for what a deposit is) a. add/mod deposit: i. add/mod Transactions 1. add/mod accounts ii. del Transactions iii. Print / Email receipts 1. Individual receipts 2. All in batch iv. Email to owners of funds a list of contributions they have received b. Reports i. Bank report Transactions a. Search for transactions Funds a. add/mod/del funds, owners b. Reports i. History Data ==== 1. Deposit - one batch of transactions (mainly checks) processed at a time (usually to go to the bank) a. Name b. Creation date c. Transactions in this deposit (see Transaction) d. Note 2. Transaction - one monetary event where money goes from an account to a fund a. Which account is sending money (see Account) b. Line items: i. Which fund is receiving money (see Fund) ii. Amount of money iii. Whether tax deductible c. Type Check i. Check number ii. Name of institution on check iii. Name on check iv. Routing number v. Account number for check vi. Who actually cut the check (used when a gift is given from a business) Money Order i. Who actually cut the money order Cash [No additional data] Electronic Fund Transfer (EFT) i. Name of institution ii. Routing number iii. Account number? d. Note 3. Account (not sure if this is the right technical accounting term for this) - a single money-sending entity. Examples would be: 1. An individual (e.g., "Joe Smith") 2. A couple (e.g., "Joe & Sue Smith") 3. A family (e.g., "The Smiths") 4. A company (e.g., "Smith's Grocery, Inc.") 5. A church/organization (e.g., "First Presbyterian Church") The data for an account would be: a. Which donor(s) own this account For each donor: i. Name ii. Sortname iii. Gender iv. Contact Information 1. Address 2. Phone number 3. E-mail address b. Note 4. Fund - a single money-receiving entity. Examples would be: 1. An individual staff (e.g., "Joe Staff") 2. A staff couple or family (e.g., "Joe & Sue Staff") 3. An organization-wide fund (e.g., "Conferences") The data for a fund would be: a. Name b. id of fund in accounting software package (we use Peachtree, and would need to export from this receipting system the total received for each fund and import those totals into the accounting system) c. Whether tax deductible d. Owners of fund e. Whether the fund is active f. Note =================== There may be some overlap in what I have shared with what you have in your Requirements Doc, Darryl, but I tried to minimize that. Let me know your thoughts! Matt ______________________________________________________________ Matthew Patton pattonm@dm.org DiscipleMakers Headquarters: (814)234-7975 x32 On Sun, 21 Mar 2004, Darryl Caldwell wrote: > Thanks Jason and Tom, > > The use case you outlined is right in line with the REQ doc that I have > written for Calendula. Many donors hang on to "thank-you" letters from > charities and other NPOs for their tax records. > > You all can view the REQ in the CVS repository or send me a note and I > will attach it to an email message to you. > > NOW would be a good time to read through the REQ to see if it is missing > something obvious. It also contains good talking points for you > consultants out there that deal with nonprofits on a regular basis, and > especially all of you on your way to NTEN/Penguinday. > > > -D > > > > > > Hi Darryl, > > > > On Sat, 20 Mar 2004, Darryl Caldwell wrote: > > > >>Thanks for the overview, Matt. Could you by chance provide us with a > >>simple use case for this receipting system. I am trying to visualize how > >>this would fit into a CRM. > > > > I'll throw in a little more to try and clarify things. By "receipting" > > what we mean is the software that our secretaries use to handle > > contributions (donations) that come to our headquarters, usually in the > > form of checks. They use the software to enter in who the gift was from, > > who it's for, and then print a receipt to mail to the donor (hence > > the name "receipting"). It would be great for this "receipting" system to > > tie into our CRM software so all of our staff (most are remote) would > > automatically see all the gifts a contact has given when they look up a > > person's record in the CRM software. > > > > The basic idea we have is to have this big database of people that all of > > our software ties into, instead of our current situation of separate > > software for the donations, CRM, event/conference management, etc. > > > > I hope that makes sense. > > > > -Jason > > _______________________________________________ > > Calendula-devel mailing list > > Calendula-devel@fudosys.com > > http://list.fudosys.com/mailman/listinfo/calendula-devel > > > > > -- > Darryl Caldwell > darrylc@fudosys.com > www.fudosys.com > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel > From darrylc@fudosys.com Wed Mar 24 17:16:16 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 81C416DD8 for ; Wed, 24 Mar 2004 17:16:16 -0600 (CST) From: Darryl Caldwell To: caldev Content-Type: text/plain Organization: Fudo Systems Message-Id: <1080170075.1282.12.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 24 Mar 2004 15:14:36 -0800 Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] Interesting FLOSS project Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Peter Hollings sent me this info: The federal Department of Housing and Urban Development (HUD) is requiring all communities that receive HUD funding (the vast majority) to implement a Homeless Management Information System (HMIS) by the end of 2004.* Homeless shelters will be entering client information into these HMIS databases, and in return communities will get unduplicated counts of homeless persons served, electronic case management tools, and better planning information. Several communities in Washington State have banded together to create an open source HMIS, the latest version of which can viewed/demoed/downloaded from: http://homeless-mis.net/ Although there are several commercial HMIS systems, as far as I know the open source HMIS is the only one fully compliant with the HUD draft HMIS Data Standard (http://www.hud.gov/offices/cpd/homeless/hmis/). -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From maasj@dm.org Fri Mar 26 10:05:39 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 972246DDD; Fri, 26 Mar 2004 10:05:39 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id CBA466DDC for ; Fri, 26 Mar 2004 10:05:07 -0600 (CST) Received: from gondor.maasj.dm.org (gondor.maasj.dm.org [192.168.11.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dm.org (Postfix) with ESMTP id 4C225235222; Fri, 26 Mar 2004 11:05:04 -0500 (EST) Date: Fri, 26 Mar 2004 11:05:02 -0500 (EST) From: Jason Maas To: Bill Bell Cc: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] DiscipleMakers weigh-in In-Reply-To: <405D4EB7.4244.31E16F89@localhost> Message-ID: References: <405D4EB7.4244.31E16F89@localhost> X-DiscipleMakers-MailScanner: Found to be clean X-MailScanner-From: maasj@dm.org X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi Bill, On Sun, 21 Mar 2004, Bill Bell wrote: >Would it be possible for you to indicate which Goldmine features are the >most heavily used? We have different groups of users based on their dependence on Goldmine (GM) and their proficiency with it. We have a few "power users" of Goldmine who are starting to using the Goldmine synchronization feature (marketed as GoldSync) to collect all their data together. Those users use it as their email client because it then associates emails with their contacts. They use the "notes" fields heavily and also the calendar. Another much-loved feature is the ability to use a modem to dial phone numbers for voice calls (thus avoiding mis-dialing). Most of our staff who use GM just use it as a PIM which can also manage snail mail (i.e. print labels) and email lists for mass mailings to their donors. If we could cover those uses and also tie it in to our donation-handing system (aka "receipting") that would be a great start. >Well _I_ find it interesting. Do you have Goldmine experience? Jason From bill-bell@bill-bell.hamilton.on.ca Fri Mar 26 12:04:50 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id E06506DDD; Fri, 26 Mar 2004 12:04:50 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id 3A8646DDC for ; Fri, 26 Mar 2004 12:04:18 -0600 (CST) Received: from default (Hamilton-ppp106927.sympatico.ca [216.209.129.144]) by smaug.vex.net (Postfix) with ESMTP id C53F625ED3; Fri, 26 Mar 2004 13:03:59 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: Jason Maas Date: Fri, 26 Mar 2004 13:03:43 -0500 Subject: Re: [Calendula-devel] DiscipleMakers weigh-in Reply-To: bill-bell@bill-bell.hamilton.on.ca Cc: calendula-devel@fudosys.com Message-ID: <40642A2F.24248.130D9F96@localhost> Priority: normal In-reply-to: References: <405D4EB7.4244.31E16F89@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 26 Mar 2004 at 11:05, Jason Maas wrote: > On Sun, 21 Mar 2004, Bill Bell wrote: > > >Would it be possible for you to indicate which Goldmine features are the > >most heavily used? > > Do you have Goldmine experience? I tried it out a few years ago, that's it! It just seemed to me that it would be valuable to know about how actual users might employ the thingy we're thinking of building. Thanks for the information. Bill From darrylc@fudosys.com Tue Mar 30 16:39:04 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 95C996DD8 for ; Tue, 30 Mar 2004 16:39:03 -0600 (CST) From: Darryl Caldwell To: caldev Content-Type: text/plain Organization: Fudo Systems Message-Id: <1080685501.2569.29.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 30 Mar 2004 14:25:07 -0800 Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] quickbooks? Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi all, Does anyone out there have a connection with a nonprofit that uses Quickbooks for nonprofits? I am just wondering how prevalent it is. This link is interesting: www.nonprofitbooks.com Has anyone looked at GNUCash and thought about its viability in a NPO setting? Also, there was some discussion here of the contact management side of a fundraising system. Notable items mentioned are Act! and Goldmine. I did a little snooping on the net. Ideas? Take a look at the demo I found: http://www.absolutebusy.com/contact_manager.html (proprietary, uses mysql, demo online) Found the following link to Contract Pro Plus, a WinX app. The page contains some interesting flash demos of their system. Great screenshots. http://www.contactplus.com/products/pro/promain.htm -Darryl -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From maasj@dm.org Tue Mar 30 20:44:39 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id C91DE6DDD; Tue, 30 Mar 2004 20:44:39 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id 2379A6DDC for ; Tue, 30 Mar 2004 20:44:07 -0600 (CST) Received: from gondor.maasj.dm.org (gondor.maasj.dm.org [192.168.11.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dm.org (Postfix) with ESMTP id 1EC9D2351FF for ; Tue, 30 Mar 2004 21:44:02 -0500 (EST) Date: Tue, 30 Mar 2004 21:43:59 -0500 (EST) From: Jason Maas To: calendula-devel@fudosys.com Message-ID: X-DiscipleMakers-MailScanner: Found to be clean X-MailScanner-From: maasj@dm.org X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Calendula-devel] Penguin Day & NTEN report? Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi all, Anyone here make it to NTEN & Penguin Day? If so, what were some of the highlights? -Jason From maasj@dm.org Tue Mar 30 21:44:41 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 23A016DDC; Tue, 30 Mar 2004 21:44:41 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id 17A576DD8; Tue, 30 Mar 2004 21:44:09 -0600 (CST) Received: from gondor.maasj.dm.org (gondor.maasj.dm.org [192.168.11.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dm.org (Postfix) with ESMTP id D4C272351FF; Tue, 30 Mar 2004 22:44:05 -0500 (EST) Date: Tue, 30 Mar 2004 22:44:02 -0500 (EST) From: Jason Maas To: Darryl Caldwell Cc: caldev Subject: Re: [Calendula-devel] quickbooks? In-Reply-To: <1080685501.2569.29.camel@dhcppc4> Message-ID: References: <1080685501.2569.29.camel@dhcppc4> X-DiscipleMakers-MailScanner: Found to be clean X-MailScanner-From: maasj@dm.org X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi Darryl, On Tue, 30 Mar 2004, Darryl Caldwell wrote: >Does anyone out there have a connection with a nonprofit that uses >Quickbooks for nonprofits? I am just wondering how prevalent it is. Not us, we are just making do with "Peachtree Complete Accounting" software for Windows (under VMWare, storing the data using Samba). It's not designed for non-profits. >Has anyone looked at GNUCash and thought about its viability in a NPO >setting? Yes! I've used GNUCash for my personal finances for about 3.5 years now. Last summer we had a couple interns with accounting degrees investigate the various OSS options for replacing Peachtree as our accounting package. They decided that there was nothing worthwhile out there, but we've since learned that people with an accounting degree and experience using shiny proprietary accounting software tend to look for certain labels and buttons. It seems that the different flavors of most commercial accounting packages all basically do the same things, but they'll be tailored for a certain market (i.e. churches/nonprofits, small retail stores, etc) and the software will have certain labels & buttons to match the target market. OSS like GNUCash is designed to be more generic and work in different markets and countries, etc. so it doesn't have special "non-profit" buttons. But I think it can do everything we do as a small non-profit. One bummer about GnuCash is that it currently only supports a single user making changes to your data. They've done some work on using an RDBMS back-end to support multiple users working on the data at the same time, but I believe that code is out of date and not complete. Another package I want to look at more is SQL-Ledger (www.sql-ledger.org) which is a web-app accounting package designed for small businesses. It can handle multiple concurrent users. Neither of those applications has an integrated payroll system for handling the paying of employees and all the taxes and fees that need to be taken out of their gross salary. But that doesn't mean that you can't use them for your payroll! Here are a couple links that discuss how to use GnuCash for payroll: http://www.gnucash.org/docs/v1.8/C/gnucash-guide/chapter14.html http://www.aerospacesoftware.com/GNU_Cash_for_Business_users_Howto_Guide.html Another option is to outsource your payroll calculations & check >http://www.absolutebusy.com/contact_manager.html (proprietary, uses >mysql, demo online) Looks a little bit interesting, but it's not nearly as featureful as Goldmine. >Found the following link to Contract Pro Plus, a WinX app. The page >contains some interesting flash demos of their system. Great >screenshots. > >http://www.contactplus.com/products/pro/promain.htm I didn't look at any of the Flash movies (blech), but I did skim through some of the info about the program, and it sounds very similar to Goldmine in purpose, scope, and pricing. It even sounds better than Goldmine in some ways (better security controls over data in a multi-user environment). This is the kind of app that an organization like DiscipleMakers would like as OSS someday. We don't have a "sales force", but all of our staff do fund raising which looks a lot like sales from a software point of view. We need a good tool to allow our staff to share information their contacts, especially in the common situation where multiple staff know a specific donor and want to see all interaction with that donor. Jason From phollings@ipt.org Wed Mar 31 12:50:02 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 0D5446DDC; Wed, 31 Mar 2004 12:50:02 -0600 (CST) Received: from smtp.xspedius.net (smtp3.xspedius.net [207.191.70.235]) by riposte.org (Postfix) with SMTP id 073526DD8 for ; Wed, 31 Mar 2004 12:49:29 -0600 (CST) Received: (qmail 28953 invoked from network); 31 Mar 2004 12:49:27 -0600 Received: from unknown (HELO IPT11) (199.227.58.163) by smtp.xspedius.net with SMTP; 31 Mar 2004 12:49:27 -0600 Reply-To: From: "Peter Hollings" To: Date: Wed, 31 Mar 2004 13:49:31 -0500 Organization: Institute for Professionals in Taxation Message-ID: <005101c41750$e791a180$8964a8c0@IPT11> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040331180001.31300.19952.Mailman@slice.riposte.org> Importance: Normal X-Spam-Status: No, hits=-4.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,ORIGINAL_MESSAGE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [Calendula-devel] RE: Calendula-devel digest, Vol 1 #16 - 3 msgs Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Many non-profits have a fundamental difference in their accounting methods from commercial enterprises. They do something called "fund accounting". Basically, what this means is that they set aside some funds earmarked for specific purposes (such as an university endowment for scholarships) and then they account for the income and expenditure of the fund. This is in addition from the organization's "general accounting".=20 Since many NPOs operate on grants, you might also consider what kind of financial recordkeeping/report making would be required.=20=20 Peter Hollings -----Original Message----- From: calendula-devel-admin@fudosys.com [mailto:calendula-devel-admin@fudosys.com] On Behalf Of calendula-devel-request@fudosys.com Sent: Wednesday, March 31, 2004 1:00 PM To: calendula-devel@fudosys.com Subject: Calendula-devel digest, Vol 1 #16 - 3 msgs Send Calendula-devel mailing list submissions to calendula-devel@fudosys.com To subscribe or unsubscribe via the World Wide Web, visit http://list.fudosys.com/mailman/listinfo/calendula-devel or, via email, send a message with subject or body 'help' to calendula-devel-request@fudosys.com You can reach the person managing the list at calendula-devel-admin@fudosys.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Calendula-devel digest..." Today's Topics: 1. quickbooks? (Darryl Caldwell) 2. Penguin Day & NTEN report? (Jason Maas) 3. Re: quickbooks? (Jason Maas) --__--__-- Message: 1 From: Darryl Caldwell To: caldev Organization: Fudo Systems Date: 30 Mar 2004 14:25:07 -0800 Subject: [Calendula-devel] quickbooks? Hi all, Does anyone out there have a connection with a nonprofit that uses Quickbooks for nonprofits? I am just wondering how prevalent it is. This link is interesting: www.nonprofitbooks.com Has anyone looked at GNUCash and thought about its viability in a NPO setting? Also, there was some discussion here of the contact management side of a fundraising system. Notable items mentioned are Act! and Goldmine. I did a little snooping on the net.=20 Ideas? Take a look at the demo I found: http://www.absolutebusy.com/contact_manager.html (proprietary, uses mysql, demo online) Found the following link to Contract Pro Plus, a WinX app. The page contains some interesting flash demos of their system. Great screenshots. http://www.contactplus.com/products/pro/promain.htm -Darryl --=20 Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" --__--__-- Message: 2 Date: Tue, 30 Mar 2004 21:43:59 -0500 (EST) From: Jason Maas To: calendula-devel@fudosys.com Subject: [Calendula-devel] Penguin Day & NTEN report? Hi all, Anyone here make it to NTEN & Penguin Day? If so, what were some of the highlights? -Jason --__--__-- Message: 3 Date: Tue, 30 Mar 2004 22:44:02 -0500 (EST) From: Jason Maas To: Darryl Caldwell Cc: caldev Subject: Re: [Calendula-devel] quickbooks? Hi Darryl, On Tue, 30 Mar 2004, Darryl Caldwell wrote: >Does anyone out there have a connection with a nonprofit that uses >Quickbooks for nonprofits? I am just wondering how prevalent it is. Not us, we are just making do with "Peachtree Complete Accounting" software for Windows (under VMWare, storing the data using Samba). It's not designed for non-profits. >Has anyone looked at GNUCash and thought about its viability in a NPO >setting? Yes! I've used GNUCash for my personal finances for about 3.5 years now. Last summer we had a couple interns with accounting degrees investigate the various OSS options for replacing Peachtree as our accounting package. They decided that there was nothing worthwhile out there, but we've since learned that people with an accounting degree and experience using shiny proprietary accounting software tend to look for certain labels and buttons. It seems that the different flavors of most commercial accounting packages all basically do the same things, but they'll be tailored for a certain market (i.e. churches/nonprofits, small retail stores, etc) and the software will have certain labels & buttons to match the target market. OSS like GNUCash is designed to be more generic and work in different markets and countries, etc. so it doesn't have special "non-profit" buttons. But I think it can do everything we do as a small non-profit. One bummer about GnuCash is that it currently only supports a single user making changes to your data. They've done some work on using an RDBMS back-end to support multiple users working on the data at the same time, but I believe that code is out of date and not complete. Another package I want to look at more is SQL-Ledger (www.sql-ledger.org) which is a web-app accounting package designed for small businesses. It can handle multiple concurrent users. Neither of those applications has an integrated payroll system for handling the paying of employees and all the taxes and fees that need to be taken out of their gross salary. But that doesn't mean that you can't use them for your payroll! Here are a couple links that discuss how to use GnuCash for payroll: http://www.gnucash.org/docs/v1.8/C/gnucash-guide/chapter14.html http://www.aerospacesoftware.com/GNU_Cash_for_Business_users_Howto_Guide .html Another option is to outsource your payroll calculations & check >http://www.absolutebusy.com/contact_manager.html (proprietary, uses >mysql, demo online) Looks a little bit interesting, but it's not nearly as featureful as Goldmine. >Found the following link to Contract Pro Plus, a WinX app. The page >contains some interesting flash demos of their system. Great >screenshots. > >http://www.contactplus.com/products/pro/promain.htm I didn't look at any of the Flash movies (blech), but I did skim through some of the info about the program, and it sounds very similar to Goldmine in purpose, scope, and pricing. It even sounds better than Goldmine in some ways (better security controls over data in a multi-user environment). This is the kind of app that an organization like DiscipleMakers would like as OSS someday. We don't have a "sales force", but all of our staff do fund raising which looks a lot like sales from a software point of view. We need a good tool to allow our staff to share information their contacts, especially in the common situation where multiple staff know a specific donor and want to see all interaction with that donor. Jason --__--__-- _______________________________________________ Calendula-devel mailing list Calendula-devel@fudosys.com http://list.fudosys.com/mailman/listinfo/calendula-devel End of Calendula-devel Digest From robergb@dm.org Wed Mar 31 13:56:13 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 27AC76DDC; Wed, 31 Mar 2004 13:56:13 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id 9FC376DD8 for ; Wed, 31 Mar 2004 13:55:40 -0600 (CST) Received: by mail.dm.org (Postfix, from userid 500) id D366BC0607; Wed, 31 Mar 2004 14:55:39 -0500 (EST) Date: Wed, 31 Mar 2004 14:55:39 -0500 To: Peter Hollings Cc: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] Accounting software Message-ID: <20040331195539.GC27963@dm.org> References: <20040331180001.31300.19952.Mailman@slice.riposte.org> <005101c41750$e791a180$8964a8c0@IPT11> In-Reply-To: <005101c41750$e791a180$8964a8c0@IPT11> User-Agent: Mutt/1.5.5.1+cvs20040105i From: robergb@dm.org (Brian Roberg) X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, Mar 31, 2004 at 01:49:31PM -0500, Peter Hollings wrote: > Many non-profits have a fundamental difference in their accounting > methods from commercial enterprises. They do something called "fund > accounting". Basically, what this means is that they set aside some > funds earmarked for specific purposes (such as an university endowment > for scholarships) and then they account for the income and expenditure > of the fund. This is in addition from the organization's "general > accounting". I'm glad you mention this, because it highlights the uncertainty and frustration that we (a small non-profit organization) have faced with respect to accounting software. When I went to the Christian Management Association conference last year, I heard all about "fund accounting" and was concerned because our software wasn't geared to do that. But I'm a sysadmin, not an accountant, so I didn't understand what everything meant. In fact, like most non-profits our size (I'd imagine), we don't have a full-time accountant. Thus none of us understand these accounting terms with any real precision. We just get by doing what we need to do. In fact, I've had trouble understanding what exactly makes fund accounting qualitatively different from what a for-profit company would use. By the definition you provided, we do fund accounting. But some accountant-types who've worked with us say what we're doing is not fund accounting. Jason was expressing the tentative conclusion we've reached, namely that people with formal training in accounting look for very particular things when they evaluate accounting software. For example, one of the guys who helped us last summer has a Master's degree in accounting. He said that GNUCash wasn't suitable for use because it doesn't have a "Chart of Accounts." He's right that it doesn't have a button that says "Chart of Accounts." But it does let you organize accounts hierarchically, manage amounts for each independently, assign codes for each account, etc. The capability is there, but the presentation of the data is not what an accountant would expect. True, it would be better if we had a system that presented things using the same terminology as the regulations we're trying to follow. But we don't have the money to buy such a system, and if GNUCash can do the same thing (if not using the right words), we'll go with that. If anyone is an expert in both accounting and GNUCash, I would love to know whether our assessment is accurate. > Since many NPOs operate on grants, you might also consider what kind of > financial recordkeeping/report making would be required. Definitely. This is very important. Brian -- Brian Roberg DiscipleMakers, Inc. W: 814-234-7975x34 H: 814-867-8327 http://www.brianroberg.org/ From maasj@dm.org Wed Mar 31 13:58:02 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 5F75F6DDD; Wed, 31 Mar 2004 13:58:02 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id BB96D6DD8 for ; Wed, 31 Mar 2004 13:57:30 -0600 (CST) Received: from noah.dm.org (noah.dm.org [216.169.168.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dm.org (Postfix) with ESMTP id E1F192351FA for ; Wed, 31 Mar 2004 14:57:26 -0500 (EST) Date: Wed, 31 Mar 2004 14:57:26 -0500 (EST) From: Jason Maas To: calendula-devel@fudosys.com Message-ID: X-DiscipleMakers-MailScanner: Found to be clean X-MailScanner-From: maasj@dm.org X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Calendula-devel] Nice website about finances for non-profits... Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi all, If you're interested in financial management procedures for non-profits, ("fund accounting", etc) check out this list of FAQs: http://www.allianceonline.org/FAQ/financial_management It seems to me to be quite well-written & even-handed, and you don't have to be a professional accountant to understand it. =) In particular, check out FAQs 9, 1, 2, and 6 among others. HTH, Jason From darrylc@fudosys.com Wed Mar 31 16:01:22 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 136B66DDC for ; Wed, 31 Mar 2004 16:01:22 -0600 (CST) From: Darryl Caldwell To: caldev In-Reply-To: References: <1080685501.2569.29.camel@dhcppc4> <32839.64.38.163.55.1080712314.squirrel@webmail.fudosys.com> Content-Type: text/plain Organization: Fudo Systems Message-Id: <1080769272.1442.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 31 Mar 2004 13:45:30 -0800 Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] thoughts on QB intergration Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On Wed, 2004-03-31 at 08:42, Jason Maas wrote: > Hi Darryl, > > What exactly are you thinking of when you say "integrating with existing > accounting packages"? > > Jason > k I mean passing data back and forth through the various hoops. If you look at the QuickBook clones for NPOs they offer hooks into accounting. Presumably, the ability to define campaigns funds to the accounting fund categories without having to enter data more than once. Raiser's Edge, Donor2 and the other big players off the same convenience. I am getting way ahead of myself, but I read this case study for a for-profit company and I started daydreaming..... http://www.openflow.it/EN/Documentation/casestudies_html -D -- Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From pattonm@dm.org Thu Apr 1 14:47:01 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 58B906DDC; Thu, 1 Apr 2004 14:47:01 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id 178C26DD8 for ; Thu, 1 Apr 2004 14:46:29 -0600 (CST) Received: by mail.dm.org (Postfix, from userid 510) id 5D89BC0607; Thu, 1 Apr 2004 15:46:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.dm.org (Postfix) with ESMTP id 41AB5164B41 for ; Thu, 1 Apr 2004 15:46:28 -0500 (EST) Date: Thu, 1 Apr 2004 15:46:28 -0500 (EST) From: Matthew Patton To: calendula-devel@fudosys.com Message-ID: X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Calendula-devel] Architecture Thoughts: J2EE vs Python Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hello everyone, It was mentioned by several of you a while back when there was a debate about which language to use that the more important thing than the specific language is the particular *architecture* we use for our program: Thomas Panzarella: "Also, I think much more important that the ultimate language is the architecture." Bill Bell: "Perhaps we can agree that we will surely fail if we do a poor job of the architecture." There was general consensus about this, and so I posted the thoughts that we (Tom, Jason, Brian, and I at DiscipleMakers) had been developing with regard to an architecture solution via an Open Source Enterprise Application Toolkit for Python. [0] I didn't hear much back from you all on this, and we have actually since been reconsidering our plans for developing these tools for Python. The reconsideration comes from looking at J2EE [1], which is a free ("as in beer", not OSS) set of tools for Java for developing just the sort of app that Calendula is to be. It handles all of the low-level "plumbing" of developing a distributed application (remote objects, HTML templating, transactions, failover, load-balancing, object messaging, etc.) and is in a much more mature state than anything in Python at the moment. We know that you all have already decided to use Python, and we don't want to start a flame war (there are many things that we like about Python), but we wanted to share with you the direction that we are leaning towards because we really would like to work with you to meet the software needs of Non-Profits if at all possible. Below is a cost-benefit analysis for either side of the decision. Would you consider it and let us know if we are overlooking anything? J2EE vs. Python Decision ======================== Python ====== Benefits of Python: ------------------- - Language is preferrable in some ways to Java: - Elegant and readable - Open source - Rapid coding: is a scripting language, so implicit typing, no need to expressly compile, etc. - Several tools that we need already exist and are viable: - Zope [2] for a server to serve up objects and handle authentication - Modeling [3] for object-relational mapping Costs of Python: ---------------- - Entire toolset not in place - Lacking: - Business Logic Framework - Would provide standards for writing business logic - Need to handle security, sessions, etc. - Advanced remote procedure calling protocol - Although there is an excellent XML-RPC library in existence [4], we still need to be able to pass objects and reference params at the bare minimum - A more advanced (but almost as necessary) feature would be allowing more than just static methods to be called (i.e.,a remote references to instances of objects on the server) - This remote object scheme is no joke to implement, and is necessary if Calendula is to be scalable and flexible in its design - Client Frameworks - All existing frameworks are too immature - We need a strong Model-View-Controller design like Struts [5] that elegantly handles the complexities of web programming (how to overcome http's statelessness, the back-button, etc.) - Ultimately, we are lacking the robustness and power and flexibility that comes from a unified solution like J2EE - Will need to implement these tools, involving: - Designing (including research which would probably involve learning lots about J2EE anyway) - Implementation (coding and testing) - Communication - Lots of documenting - SF website management - Mailing lists - Example project (I said before this would not take more than a few months, but consider this: a couple months before an *ALPHA* version that doesn't do more than a fraction of what J2EE does and that will be in considerable flux until we stabilize our design ideas) - Those tools that are already available have issues: - Zope: docs are hard to understand - Modeling: still Beta, only partial implementation of Apple's Enterprise Object Framework, head developer is very attentive but is working on it basically alone in his free time Summary: Python as a language is superior to Java in many ways, but it lacks some of the tools that we need if we are to have an excellent architecture to build a long-lasting solution on top of. We could write our own tools, but they would be immature and inferior for some time, and would require considerable effort to implement and maintain. J2EE ==== Benefits of J2EE: ----------------- - Complete, mature toolset already in place - JBoss is an OSS alternative to Sun's J2EE implementation - Good documentation (sometimes hard to understand, but very extensive, professional, and complete) - Design done by people who know what they're doing (more than us, anyway) - Good design means that we can use some tools and technologies and not use others that we don't want or need, thus keeping complexity at a minimum - J2EE toolset implements many things that Python lacks: - Excellent client frameworks (both with Struts and the J2EE frameworks) - Servlet approach better than the one-time executing scripts - Model-View-Controller concepts in both Struts and J2EE - Enterprise Java Beans (EJB) are extremely powerful - (MOST IMPORTANT) Allows encapsulation of how data is stored and the complexities of the business logic (hides this from client) through a remotely accessible API - Very nice and flexible object-relational layer (with Hibernate as another excellent OSS possibility) - Allows transactions of large operations that can be rolled back (larger in scope than just DB transactions) - Provides means for handling data security - Helpful links to learn the basics: http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html (Beginner's overview) http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html (Tutorial for J2EE, check out Chapter 27: Method Invocations in RosterApp for code examples) - Distributed objects via excellent communication systems - Java Remote Method Invocation (RMI) allows remote access of EJB's and transmission of complex data types and exceptions - Asynchronous messaging between objects - Managing and deploying web services - Provides all the robustness of a high-quality server: scalability, reliability (failover), extensibility, load balancing, component hotswapping, security - Java a widely used language - Lots of other OSS tools available (Ant, Struts, etc.) - Many resources for developers - Large development community: broad industry support and credibility Costs of J2EE: -------------- - Language issues: - Not open source at the moment - Can be verbose - Problems arise when trying to make different versions of Java co-exist - Clunkiness of UI's (perhaps attenuated by wxWidgets?) - Learning curve: too complex for our needs? - Attenuated by the fact that not everyone needs to know the entire J2EE spec, just the parts that pertain to them (JSP, EJB, etc.) - Don't need to use ALL of their technologies, just the ones we need - It takes a while to wade through the docs and all of the acronyms, but it begins to make sense eventually. At least it lacks a lot of the complex and arcane wierdness that an immature system inevitably has. - With JBoss we would have to pay for docs beyond the tutorial (may not be necessary for our purposes) Summary: J2EE is an excellent toolset that has basically everything we need and much more, although the Java language itself has some (minor?) issues. ------------------------------------- That's what I have gathered from our research and your input. What motivates us in all of this is the conviction that excellent business software needs to be written in a layered, distributed, n-tier approach with the layers clearly delineated and abstracted, and so we are seeking the best tools that will enable us to do this. Please correct me on any areas where you think what I have said is incorrect, or if you think there is anything I'm overlooking. I recognize that since you are a GNU project there may be restrictions to using a non-Free language like Java. Java is: "Free for development, production deployment, and redistribution" [6] but it is NOT Open Source. There are attempts to reproduce Java as Open Source, but as I understand it these are only at the point of Java Virtual Machine (JVM) 1.2, and not at 1.4, which is what JBoss requires. At this point, I'd say we (here at DM) are getting close to making a decision as to which direction to pursue, and are leaning towards the J2EE option, but we would welcome comments from you all. Thanks, Matt [0] http://list.fudosys.com/pipermail/calendula-devel/2004-March/000040.html [1] http://java.sun.com/j2ee/ [2] http://www.zope.org [3] http://modeling.sourceforge.net/ [4] http://www.pythonware.com/products/xmlrpc/ [5] http://jakarta.apache.org/struts/ [6] http://java.sun.com/j2ee/1.4/download.html#sdk ______________________________________________________________ Matthew Patton pattonm@dm.org DiscipleMakers Headquarters: (814)234-7975 x32 From tpanzarella@mac.com Thu Apr 1 16:42:11 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 0BECC6DDD; Thu, 1 Apr 2004 16:42:11 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-88.apple.com [17.250.248.88]) by riposte.org (Postfix) with ESMTP id C461D6DD8 for ; Thu, 1 Apr 2004 16:41:38 -0600 (CST) Received: from webmail01.mac.com (webmail01-en1 [10.13.11.143]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i31Mfci1007054 for ; Thu, 1 Apr 2004 14:41:38 -0800 (PST) Received: from webmail01 (localhost [127.0.0.1]) by webmail01.mac.com (8.12.6/8.12.2) with ESMTP id i31Mfbic024707 for ; Thu, 1 Apr 2004 14:41:37 -0800 (PST) Message-ID: <5204302.1080859297732.JavaMail.tpanzarella@mac.com> Date: Thu, 01 Apr 2004 17:41:37 -0500 From: Tom Panzarella To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: There is a lot of information here but I think it warrants more input. I h= ave to confess up front that some of what I say may be biased due to the fa= ct that I am primarily a Java/J2EE developer although I have reasonable exp= erience with Python -- I just really like Java. In general I agree with wh= at Matt is saying but I think there are more things to consider.=20=20 Yes, J2EE is a more robust framework for building distributed object orient= ed applications than anything Python has to offer. I'm not trying to diss = Python at all, I just prefer to use a hammer to bang in a nail and a fork t= o eat my food unless it is soup in which case I prefer a spoon. If that an= alogy makes any sense, what I'm saying is Java/J2EE IS a better choice for = large (define as you wish) distributed business applications than Python. A= nd Python is a better choice than Java for things like mailing list manag= ers (ala Mailman). I still want to stress that I think that architecture is much more importan= t than implementation language/platform. I've seen some real "train wreck"= J2EE apps which I think are partially due to the fact that the developers = don't fully understand what they are doing. One thing that Java/J2EE lends= itself to (beyond all of the acronyms ... more on that later) is the effec= tive use of design patterns and a community willing to share and document t= hem in a standard format. For example, a popular thing today in the J2EE c= ommunity is to NOT use CMP and EJB but rather use ORM tools and frameworks = (i.e. Hibernate, OJB, TopLink, etc.) to implement a persistence tier for sa= ving the state of POJOs (Plain old java objects) within distributed apps. = Best practices and patterns that have developed around EJB to allow for net= work transparency and such have also been modified to support these other a= lternative frameworks. Getting specific now is way beyond the scope of thi= s email. The major issue for this project I think is two-fold: 1) skills 2) the proj= ect leader already declared Python. On the first point, if you are just en= tering the J2EE world, it's not something you are going to just pick up. I= f you are already a Java programmer and have some experience with design pa= tterns you have a better shot of breaking down the barriers to entry. I'm = not saying that the developers on this list can't do it, I'm just saying th= at it will take some time to learn all the appropriate pieces and how they = interact with eachother -- there is a lot of crap to learn. Honestly, the = first real hurdle I see developers who come from scripting environments hav= e to get over is the fact that they actually have to compile their code, ru= n unit tests (well you should at least), and then deploy -- it's not just e= dit the code, "C-x C-s", then hit "refresh" on your browser. I've made some particular comments in-line with Matt's email below ..... =20 > > It was mentioned by several of you a while back when there was a >debate about which language to use that the more important thing than the >specific language is the particular *architecture* we use for our program: > >Thomas Panzarella: "Also, I think much more important that the ultimate >language is the architecture." > Nice comment, who's that guy ;-) > >Bill Bell: "Perhaps we can agree that we will surely fail if we do a poor >job of the architecture." > Agreed. > > I didn't hear much back from you all on this, and we have actually >since been reconsidering our plans for developing these tools for Python. >The reconsideration comes from looking at J2EE [1], which is a free ("as >in beer", not OSS) set of tools for Java for developing just the sort of >app that Calendula is to be.=20=20 > A quick word on this. Java is not OSS as defined by OSI (http://www.openso= urce.org) but you can access the source to the the Java platform via the Su= n Community Source License which let's you do whatever you want except for = fork the platform. Then of course if you do build your own Java implementa= tion (for some odd reason) you will certainly have to pay license fees to S= un to get certified as pure Java. As for J2EE, Tomcat (http://jakarta.apac= he.org) is already the reference implementation for the Servlet/JSP/JSF pie= ce of J2EE (so the source is readily available for that) and just recently = Sun granted Apache a "scholorship" to build Geronimo (an EJB container) whi= ch will be allowed to receive J2EE certification (something that JBoss does= not have -- totally different conversation there). It should also be note= d that most of the "stuff" that Java/J2EE developers use on a daily basis a= ll comes from the OSS community and Java itself has a very vibrant OSS comm= unity rallying around it. I can go on for days on this (especially since I= ran a discussion at Penguin Day on this exact topic) but I will spare ever= yone the details. For the curious, you can get the full source to the J2SE here: http://wwws.sun.com/software/communitysource/j2se/java2//download.html > >J2EE vs. Python Decision >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Python >=3D=3D=3D=3D=3D=3D > >Benefits of Python: >------------------- > >- Language is preferrable in some ways to Java: > - Elegant and readable This is not fact but rather one opinion. Here is a funny interpretation of= someone who thinks just the opposite: Full text of this blog entry can be found here: http://www.theserverside.com/blogs/showblog.tss?id=3DGroovyReview --- start of quote --- Put in the simplest terms, it [Python] feels like a very annoying language = to me. Writing 'lambda' all of the place seems the height of silliness. The= y can keep their 'self'. Double underscores get real old real fast - even i= n just a few hours. "def"? "DEF"? WTF? I don't think I can use a language t= hat defines methods with a keyword "DEF" (aside: And I'm pissed that Groovy= requires DEF, but at least its only in one specific case). --- end of quote --- > >Summary: Python as a language is superior to Java in many ways,=20 > I'd change that line to: "Python as a language is better suited to certain = tasks than Java." > > >J2EE >=3D=3D=3D=3D > >Benefits of J2EE: >----------------- > >- Complete, mature toolset already in place > - JBoss is an OSS alternative to Sun's J2EE implementation True, but at this point I'd only suggest using JBoss if you want to use EJB= which is not necessary and sometimes undesirable in J2EE apps. EJB has a = lot of overhead to it that the marketing folk don't like to mention. But t= hen again that is why there is JDO and other object relational persistance = frameworks out there. > >- J2EE toolset implements many things that Python lacks: > - Excellent client frameworks (both with Struts and the J2EE > frameworks) > I will echo the praises of Struts. (Twinkle Twinkle -- inside joke for tho= se who made it to Penguine Day ;-) > > - Servlet approach better than the one-time executing > scripts > Yep. And it's multithreaded nature make it *better* than things like FastCG= I or mod_perl as well. ... aside: Sorry Perl people I mean no harm, I am a big Perl / mod_perl fan= as well > > - Model-View-Controller concepts in both Struts and J2EE > True. But MVC will only be one pattern necessary for an overall sound arch= itecture. > > - Enterprise Java Beans (EJB) are extremely powerful > True but not the only option. > > - (MOST IMPORTANT) Allows encapsulation of how data is > stored and the complexities of the business logic (hides > this from client) through a remotely accessible API > You don't need EJB for that .. you just need to write clean interfaces and = apply the appropriate patterns. I think what EJB is good at is all of the = "stuff" the container gives you: CMP - Container managed persistence for entity beans will keep your databas= e and distributed components' state in synch without a single line of SQL w= ritten by you. Network transparency - "clients" of EJBs don't have to know where the heck = they are. You look them up in a registry (JNDI) and then call methods on t= he bean's public interface. There is more: security, transactions, etc. > > - Very nice and flexible object-relational layer (with > Hibernate as another excellent OSS possibility) > Yep. You can use Hibernate outside of EJB as well. Also check out OJB: http://db.apache.org/ojb/ > > - Allows transactions of large operations that can be > rolled back (larger in scope than just DB transactions) > - Provides means for handling data security > - Helpful links to learn the basics: > http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html > (Beginner's overview) > http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html > (Tutorial for J2EE, check out Chapter 27: Method > Invocations in RosterApp for code examples) > > - Distributed objects via excellent communication systems > - Java Remote Method Invocation (RMI) allows remote access > of EJB's and transmission of complex data types and > exceptions > You can use RMI in standalone mode as well if you choose not to use EJB but= still want to make calls on remote objects or send serialized objects acro= ss the wire between virutal machines. > > - Asynchronous messaging between objects > > - Managing and deploying web services > > - Provides all the robustness of a high-quality server: > scalability, reliability (failover), extensibility, > load balancing, component hotswapping, security > >- Java a widely used language > - Lots of other OSS tools available (Ant, Struts, etc.) > Lots lots lots. Ant is a key peice of technology for managing the build an= d deployment of Java projects. The other real staples I'd say are JUnit and= XDoclet (especially if you are doing EJB). Middlegen is also very useful. > > - Many resources for developers > - Large development community: broad industry support and > credibility > One other "biggie" for Java that I'd throw in is built in support for easil= y building Internationalized applications. Struts also builds on Java's al= ready excellent ResourceBundle framework. > >Costs of J2EE: >-------------- > >- Language issues: > - Not open source at the moment > - Can be verbose > True but it's getting better. "Tiger" (J2SE 1.5.0) will have autoboxing an= d unboxing of variables so that will cut down on the amount of explicit typ= e casts that clutter up Java code. And if you can follow it, many of the A= PIs have been designed in such a way to promote method invocation chaining = which also tends to save a few key strokes here and there. I guess this is= one of the things that Groovy (http://groovy.codehaus.org/) is addressing. > > - Problems arise when trying to make different versions of Java > co-exist > unlike inconsistences in C libraries on UNIX systems? Or "dll hell" on Win= dows? I don't think you can fault Java for this ... this is pretty much acr= oss the board in computing -- regardless of claims for "backward compatibil= ity". > > - Clunkiness of UI's (perhaps attenuated by wxWidgets?) > Matter of opinion. I tend to like Swing. But perhaps you'd prefer SWT: http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html > >- Learning curve: too complex for our needs? > - Attenuated by the fact that not everyone needs to know the > entire J2EE spec, just the parts that pertain to them (JSP, EJB, > etc.) > It's a constant learning process. Certainly not going to happen overnight = but it's doable. > > - Don't need to use ALL of their technologies, just the ones we > need > This cannot be stressed enough. Don't make it more overwhelming than it al= ready is. > > - It takes a while to wade through the docs and all of the > acronyms, but it begins to make sense eventually. At least it > lacks a lot of the complex and arcane wierdness that an immature > system inevitably has. > As far as the acronyms go, they are all marketing. They simply give a name= to a piece of the functionality the API has to offer. Focus on concepts a= nd not acronyms. > >- With JBoss we would have to pay for docs beyond the tutorial (may not be >necessary for our purposes) > If you aren't going to use EJB, I'd say don't use JBoss. There has been a = bit of skeptism as of late about their fearless leader (I am not going to n= ame names here). I think the community will adapt Geronimo as the defacto = open source certified J2EE container once it gets built -- this statement i= s based on Apache's already proven track record. Technically, JBoss is great. You can also check out Resin as well which im= plements thier own version of doing CMP -- not J2EE certified but still pre= tty nice. You can check out Resin here: http://www.caucho.com/ > >Summary: J2EE is an excellent toolset that has basically everything we >need and much more, although the Java language itself has some (minor?) >issues. > >------------------------------------- > >That's what I have gathered from our research and your input. What >motivates us in all of this is the conviction that excellent business >software needs to be written in a layered, distributed, n-tier approach >with the layers clearly delineated and abstracted, and so we are seeking >the best tools that will enable us to do this. Please correct me on any >areas where you think what I have said is incorrect, or if you think there >is anything I'm overlooking. > I recognize that since you are a GNU project there may be >restrictions to using a non-Free language like Java. Java is: >"Free for development, production deployment, and redistribution" [6] >but it is NOT Open Source. There are attempts to reproduce Java as Open >Source, but as I understand it these are only at the point of Java Virtual >Machine (JVM) 1.2, and not at 1.4, which is what JBoss requires. > At this point, I'd say we (here at DM) are getting close to making >a decision as to which direction to pursue, and are leaning towards the >J2EE option, but we would welcome comments from you all. > Where is your project page again? From tpanzarella@mac.com Thu Apr 1 16:42:16 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 972E96DD8; Thu, 1 Apr 2004 16:42:16 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-89.apple.com [17.250.248.89]) by riposte.org (Postfix) with ESMTP id C62806DDC for ; Thu, 1 Apr 2004 16:41:43 -0600 (CST) Received: from webmail01.mac.com (webmail01-en1 [10.13.11.143]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i31Mfh52005201 for ; Thu, 1 Apr 2004 14:41:43 -0800 (PST) Received: from webmail01 (localhost [127.0.0.1]) by webmail01.mac.com (8.12.6/8.12.2) with ESMTP id i31Mfhic024710 for ; Thu, 1 Apr 2004 14:41:43 -0800 (PST) Message-ID: <12600736.1080859303026.JavaMail.tpanzarella@mac.com> Date: Thu, 01 Apr 2004 17:41:43 -0500 From: Tom Panzarella To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: There is a lot of information here but I think it warrants more input. I h= ave to confess up front that some of what I say may be biased due to the fa= ct that I am primarily a Java/J2EE developer although I have reasonable exp= erience with Python -- I just really like Java. In general I agree with wh= at Matt is saying but I think there are more things to consider.=20=20 Yes, J2EE is a more robust framework for building distributed object orient= ed applications than anything Python has to offer. I'm not trying to diss = Python at all, I just prefer to use a hammer to bang in a nail and a fork t= o eat my food unless it is soup in which case I prefer a spoon. If that an= alogy makes any sense, what I'm saying is Java/J2EE IS a better choice for = large (define as you wish) distributed business applications than Python. A= nd Python is a better choice than Java for things like mailing list manag= ers (ala Mailman). I still want to stress that I think that architecture is much more importan= t than implementation language/platform. I've seen some real "train wreck"= J2EE apps which I think are partially due to the fact that the developers = don't fully understand what they are doing. One thing that Java/J2EE lends= itself to (beyond all of the acronyms ... more on that later) is the effec= tive use of design patterns and a community willing to share and document t= hem in a standard format. For example, a popular thing today in the J2EE c= ommunity is to NOT use CMP and EJB but rather use ORM tools and frameworks = (i.e. Hibernate, OJB, TopLink, etc.) to implement a persistence tier for sa= ving the state of POJOs (Plain old java objects) within distributed apps. = Best practices and patterns that have developed around EJB to allow for net= work transparency and such have also been modified to support these other a= lternative frameworks. Getting specific now is way beyond the scope of thi= s email. The major issue for this project I think is two-fold: 1) skills 2) the proj= ect leader already declared Python. On the first point, if you are just en= tering the J2EE world, it's not something you are going to just pick up. I= f you are already a Java programmer and have some experience with design pa= tterns you have a better shot of breaking down the barriers to entry. I'm = not saying that the developers on this list can't do it, I'm just saying th= at it will take some time to learn all the appropriate pieces and how they = interact with eachother -- there is a lot of crap to learn. Honestly, the = first real hurdle I see developers who come from scripting environments hav= e to get over is the fact that they actually have to compile their code, ru= n unit tests (well you should at least), and then deploy -- it's not just e= dit the code, "C-x C-s", then hit "refresh" on your browser. I've made some particular comments in-line with Matt's email below ..... =20 > > It was mentioned by several of you a while back when there was a >debate about which language to use that the more important thing than the >specific language is the particular *architecture* we use for our program: > >Thomas Panzarella: "Also, I think much more important that the ultimate >language is the architecture." > Nice comment, who's that guy ;-) > >Bill Bell: "Perhaps we can agree that we will surely fail if we do a poor >job of the architecture." > Agreed. > > I didn't hear much back from you all on this, and we have actually >since been reconsidering our plans for developing these tools for Python. >The reconsideration comes from looking at J2EE [1], which is a free ("as >in beer", not OSS) set of tools for Java for developing just the sort of >app that Calendula is to be.=20=20 > A quick word on this. Java is not OSS as defined by OSI (http://www.openso= urce.org) but you can access the source to the the Java platform via the Su= n Community Source License which let's you do whatever you want except for = fork the platform. Then of course if you do build your own Java implementa= tion (for some odd reason) you will certainly have to pay license fees to S= un to get certified as pure Java. As for J2EE, Tomcat (http://jakarta.apac= he.org) is already the reference implementation for the Servlet/JSP/JSF pie= ce of J2EE (so the source is readily available for that) and just recently = Sun granted Apache a "scholorship" to build Geronimo (an EJB container) whi= ch will be allowed to receive J2EE certification (something that JBoss does= not have -- totally different conversation there). It should also be note= d that most of the "stuff" that Java/J2EE developers use on a daily basis a= ll comes from the OSS community and Java itself has a very vibrant OSS comm= unity rallying around it. I can go on for days on this (especially since I= ran a discussion at Penguin Day on this exact topic) but I will spare ever= yone the details. For the curious, you can get the full source to the J2SE here: http://wwws.sun.com/software/communitysource/j2se/java2//download.html > >J2EE vs. Python Decision >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Python >=3D=3D=3D=3D=3D=3D > >Benefits of Python: >------------------- > >- Language is preferrable in some ways to Java: > - Elegant and readable This is not fact but rather one opinion. Here is a funny interpretation of= someone who thinks just the opposite: Full text of this blog entry can be found here: http://www.theserverside.com/blogs/showblog.tss?id=3DGroovyReview --- start of quote --- Put in the simplest terms, it [Python] feels like a very annoying language = to me. Writing 'lambda' all of the place seems the height of silliness. The= y can keep their 'self'. Double underscores get real old real fast - even i= n just a few hours. "def"? "DEF"? WTF? I don't think I can use a language t= hat defines methods with a keyword "DEF" (aside: And I'm pissed that Groovy= requires DEF, but at least its only in one specific case). --- end of quote --- > >Summary: Python as a language is superior to Java in many ways,=20 > I'd change that line to: "Python as a language is better suited to certain = tasks than Java." > > >J2EE >=3D=3D=3D=3D > >Benefits of J2EE: >----------------- > >- Complete, mature toolset already in place > - JBoss is an OSS alternative to Sun's J2EE implementation True, but at this point I'd only suggest using JBoss if you want to use EJB= which is not necessary and sometimes undesirable in J2EE apps. EJB has a = lot of overhead to it that the marketing folk don't like to mention. But t= hen again that is why there is JDO and other object relational persistance = frameworks out there. > >- J2EE toolset implements many things that Python lacks: > - Excellent client frameworks (both with Struts and the J2EE > frameworks) > I will echo the praises of Struts. (Twinkle Twinkle -- inside joke for tho= se who made it to Penguine Day ;-) > > - Servlet approach better than the one-time executing > scripts > Yep. And it's multithreaded nature make it *better* than things like FastCG= I or mod_perl as well. ... aside: Sorry Perl people I mean no harm, I am a big Perl / mod_perl fan= as well > > - Model-View-Controller concepts in both Struts and J2EE > True. But MVC will only be one pattern necessary for an overall sound arch= itecture. > > - Enterprise Java Beans (EJB) are extremely powerful > True but not the only option. > > - (MOST IMPORTANT) Allows encapsulation of how data is > stored and the complexities of the business logic (hides > this from client) through a remotely accessible API > You don't need EJB for that .. you just need to write clean interfaces and = apply the appropriate patterns. I think what EJB is good at is all of the = "stuff" the container gives you: CMP - Container managed persistence for entity beans will keep your databas= e and distributed components' state in synch without a single line of SQL w= ritten by you. Network transparency - "clients" of EJBs don't have to know where the heck = they are. You look them up in a registry (JNDI) and then call methods on t= he bean's public interface. There is more: security, transactions, etc. > > - Very nice and flexible object-relational layer (with > Hibernate as another excellent OSS possibility) > Yep. You can use Hibernate outside of EJB as well. Also check out OJB: http://db.apache.org/ojb/ > > - Allows transactions of large operations that can be > rolled back (larger in scope than just DB transactions) > - Provides means for handling data security > - Helpful links to learn the basics: > http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html > (Beginner's overview) > http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html > (Tutorial for J2EE, check out Chapter 27: Method > Invocations in RosterApp for code examples) > > - Distributed objects via excellent communication systems > - Java Remote Method Invocation (RMI) allows remote access > of EJB's and transmission of complex data types and > exceptions > You can use RMI in standalone mode as well if you choose not to use EJB but= still want to make calls on remote objects or send serialized objects acro= ss the wire between virutal machines. > > - Asynchronous messaging between objects > > - Managing and deploying web services > > - Provides all the robustness of a high-quality server: > scalability, reliability (failover), extensibility, > load balancing, component hotswapping, security > >- Java a widely used language > - Lots of other OSS tools available (Ant, Struts, etc.) > Lots lots lots. Ant is a key peice of technology for managing the build an= d deployment of Java projects. The other real staples I'd say are JUnit and= XDoclet (especially if you are doing EJB). Middlegen is also very useful. > > - Many resources for developers > - Large development community: broad industry support and > credibility > One other "biggie" for Java that I'd throw in is built in support for easil= y building Internationalized applications. Struts also builds on Java's al= ready excellent ResourceBundle framework. > >Costs of J2EE: >-------------- > >- Language issues: > - Not open source at the moment > - Can be verbose > True but it's getting better. "Tiger" (J2SE 1.5.0) will have autoboxing an= d unboxing of variables so that will cut down on the amount of explicit typ= e casts that clutter up Java code. And if you can follow it, many of the A= PIs have been designed in such a way to promote method invocation chaining = which also tends to save a few key strokes here and there. I guess this is= one of the things that Groovy (http://groovy.codehaus.org/) is addressing. > > - Problems arise when trying to make different versions of Java > co-exist > unlike inconsistences in C libraries on UNIX systems? Or "dll hell" on Win= dows? I don't think you can fault Java for this ... this is pretty much acr= oss the board in computing -- regardless of claims for "backward compatibil= ity". > > - Clunkiness of UI's (perhaps attenuated by wxWidgets?) > Matter of opinion. I tend to like Swing. But perhaps you'd prefer SWT: http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html > >- Learning curve: too complex for our needs? > - Attenuated by the fact that not everyone needs to know the > entire J2EE spec, just the parts that pertain to them (JSP, EJB, > etc.) > It's a constant learning process. Certainly not going to happen overnight = but it's doable. > > - Don't need to use ALL of their technologies, just the ones we > need > This cannot be stressed enough. Don't make it more overwhelming than it al= ready is. > > - It takes a while to wade through the docs and all of the > acronyms, but it begins to make sense eventually. At least it > lacks a lot of the complex and arcane wierdness that an immature > system inevitably has. > As far as the acronyms go, they are all marketing. They simply give a name= to a piece of the functionality the API has to offer. Focus on concepts a= nd not acronyms. > >- With JBoss we would have to pay for docs beyond the tutorial (may not be >necessary for our purposes) > If you aren't going to use EJB, I'd say don't use JBoss. There has been a = bit of skeptism as of late about their fearless leader (I am not going to n= ame names here). I think the community will adapt Geronimo as the defacto = open source certified J2EE container once it gets built -- this statement i= s based on Apache's already proven track record. Technically, JBoss is great. You can also check out Resin as well which im= plements thier own version of doing CMP -- not J2EE certified but still pre= tty nice. You can check out Resin here: http://www.caucho.com/ > >Summary: J2EE is an excellent toolset that has basically everything we >need and much more, although the Java language itself has some (minor?) >issues. > >------------------------------------- > >That's what I have gathered from our research and your input. What >motivates us in all of this is the conviction that excellent business >software needs to be written in a layered, distributed, n-tier approach >with the layers clearly delineated and abstracted, and so we are seeking >the best tools that will enable us to do this. Please correct me on any >areas where you think what I have said is incorrect, or if you think there >is anything I'm overlooking. > I recognize that since you are a GNU project there may be >restrictions to using a non-Free language like Java. Java is: >"Free for development, production deployment, and redistribution" [6] >but it is NOT Open Source. There are attempts to reproduce Java as Open >Source, but as I understand it these are only at the point of Java Virtual >Machine (JVM) 1.2, and not at 1.4, which is what JBoss requires. > At this point, I'd say we (here at DM) are getting close to making >a decision as to which direction to pursue, and are leaning towards the >J2EE option, but we would welcome comments from you all. > Where is your project page again? From tpanzarella@mac.com Thu Apr 1 16:43:06 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id F41726DDC; Thu, 1 Apr 2004 16:43:05 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-86.apple.com [17.250.248.86]) by riposte.org (Postfix) with ESMTP id B281A6DD8 for ; Thu, 1 Apr 2004 16:42:33 -0600 (CST) Received: from webmail01.mac.com (webmail01-en1 [10.13.11.143]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i31MgX4r001652 for ; Thu, 1 Apr 2004 14:42:33 -0800 (PST) Received: from webmail01 (localhost [127.0.0.1]) by webmail01.mac.com (8.12.6/8.12.2) with ESMTP id i31MgWic024713 for ; Thu, 1 Apr 2004 14:42:32 -0800 (PST) Message-ID: <3405862.1080859352673.JavaMail.tpanzarella@mac.com> Date: Thu, 01 Apr 2004 17:42:32 -0500 From: Tom Panzarella To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: There is a lot of information here but I think it warrants more input. I h= ave to confess up front that some of what I say may be biased due to the fa= ct that I am primarily a Java/J2EE developer although I have reasonable exp= erience with Python -- I just really like Java. In general I agree with wh= at Matt is saying but I think there are more things to consider.=20=20 Yes, J2EE is a more robust framework for building distributed object orient= ed applications than anything Python has to offer. I'm not trying to diss = Python at all, I just prefer to use a hammer to bang in a nail and a fork t= o eat my food unless it is soup in which case I prefer a spoon. If that an= alogy makes any sense, what I'm saying is Java/J2EE IS a better choice for = large (define as you wish) distributed business applications than Python. A= nd Python is a better choice than Java for things like mailing list manag= ers (ala Mailman). I still want to stress that I think that architecture is much more importan= t than implementation language/platform. I've seen some real "train wreck"= J2EE apps which I think are partially due to the fact that the developers = don't fully understand what they are doing. One thing that Java/J2EE lends= itself to (beyond all of the acronyms ... more on that later) is the effec= tive use of design patterns and a community willing to share and document t= hem in a standard format. For example, a popular thing today in the J2EE c= ommunity is to NOT use CMP and EJB but rather use ORM tools and frameworks = (i.e. Hibernate, OJB, TopLink, etc.) to implement a persistence tier for sa= ving the state of POJOs (Plain old java objects) within distributed apps. = Best practices and patterns that have developed around EJB to allow for net= work transparency and such have also been modified to support these other a= lternative frameworks. Getting specific now is way beyond the scope of thi= s email. The major issue for this project I think is two-fold: 1) skills 2) the proj= ect leader already declared Python. On the first point, if you are just en= tering the J2EE world, it's not something you are going to just pick up. I= f you are already a Java programmer and have some experience with design pa= tterns you have a better shot of breaking down the barriers to entry. I'm = not saying that the developers on this list can't do it, I'm just saying th= at it will take some time to learn all the appropriate pieces and how they = interact with eachother -- there is a lot of crap to learn. Honestly, the = first real hurdle I see developers who come from scripting environments hav= e to get over is the fact that they actually have to compile their code, ru= n unit tests (well you should at least), and then deploy -- it's not just e= dit the code, "C-x C-s", then hit "refresh" on your browser. I've made some particular comments in-line with Matt's email below ..... =20 > > It was mentioned by several of you a while back when there was a >debate about which language to use that the more important thing than the >specific language is the particular *architecture* we use for our program: > >Thomas Panzarella: "Also, I think much more important that the ultimate >language is the architecture." > Nice comment, who's that guy ;-) > >Bill Bell: "Perhaps we can agree that we will surely fail if we do a poor >job of the architecture." > Agreed. > > I didn't hear much back from you all on this, and we have actually >since been reconsidering our plans for developing these tools for Python. >The reconsideration comes from looking at J2EE [1], which is a free ("as >in beer", not OSS) set of tools for Java for developing just the sort of >app that Calendula is to be.=20=20 > A quick word on this. Java is not OSS as defined by OSI (http://www.openso= urce.org) but you can access the source to the the Java platform via the Su= n Community Source License which let's you do whatever you want except for = fork the platform. Then of course if you do build your own Java implementa= tion (for some odd reason) you will certainly have to pay license fees to S= un to get certified as pure Java. As for J2EE, Tomcat (http://jakarta.apac= he.org) is already the reference implementation for the Servlet/JSP/JSF pie= ce of J2EE (so the source is readily available for that) and just recently = Sun granted Apache a "scholorship" to build Geronimo (an EJB container) whi= ch will be allowed to receive J2EE certification (something that JBoss does= not have -- totally different conversation there). It should also be note= d that most of the "stuff" that Java/J2EE developers use on a daily basis a= ll comes from the OSS community and Java itself has a very vibrant OSS comm= unity rallying around it. I can go on for days on this (especially since I= ran a discussion at Penguin Day on this exact topic) but I will spare ever= yone the details. For the curious, you can get the full source to the J2SE here: http://wwws.sun.com/software/communitysource/j2se/java2//download.html > >J2EE vs. Python Decision >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Python >=3D=3D=3D=3D=3D=3D > >Benefits of Python: >------------------- > >- Language is preferrable in some ways to Java: > - Elegant and readable This is not fact but rather one opinion. Here is a funny interpretation of= someone who thinks just the opposite: Full text of this blog entry can be found here: http://www.theserverside.com/blogs/showblog.tss?id=3DGroovyReview --- start of quote --- Put in the simplest terms, it [Python] feels like a very annoying language = to me. Writing 'lambda' all of the place seems the height of silliness. The= y can keep their 'self'. Double underscores get real old real fast - even i= n just a few hours. "def"? "DEF"? WTF? I don't think I can use a language t= hat defines methods with a keyword "DEF" (aside: And I'm pissed that Groovy= requires DEF, but at least its only in one specific case). --- end of quote --- > >Summary: Python as a language is superior to Java in many ways,=20 > I'd change that line to: "Python as a language is better suited to certain = tasks than Java." > > >J2EE >=3D=3D=3D=3D > >Benefits of J2EE: >----------------- > >- Complete, mature toolset already in place > - JBoss is an OSS alternative to Sun's J2EE implementation True, but at this point I'd only suggest using JBoss if you want to use EJB= which is not necessary and sometimes undesirable in J2EE apps. EJB has a = lot of overhead to it that the marketing folk don't like to mention. But t= hen again that is why there is JDO and other object relational persistance = frameworks out there. > >- J2EE toolset implements many things that Python lacks: > - Excellent client frameworks (both with Struts and the J2EE > frameworks) > I will echo the praises of Struts. (Twinkle Twinkle -- inside joke for tho= se who made it to Penguine Day ;-) > > - Servlet approach better than the one-time executing > scripts > Yep. And it's multithreaded nature make it *better* than things like FastCG= I or mod_perl as well. ... aside: Sorry Perl people I mean no harm, I am a big Perl / mod_perl fan= as well > > - Model-View-Controller concepts in both Struts and J2EE > True. But MVC will only be one pattern necessary for an overall sound arch= itecture. > > - Enterprise Java Beans (EJB) are extremely powerful > True but not the only option. > > - (MOST IMPORTANT) Allows encapsulation of how data is > stored and the complexities of the business logic (hides > this from client) through a remotely accessible API > You don't need EJB for that .. you just need to write clean interfaces and = apply the appropriate patterns. I think what EJB is good at is all of the = "stuff" the container gives you: CMP - Container managed persistence for entity beans will keep your databas= e and distributed components' state in synch without a single line of SQL w= ritten by you. Network transparency - "clients" of EJBs don't have to know where the heck = they are. You look them up in a registry (JNDI) and then call methods on t= he bean's public interface. There is more: security, transactions, etc. > > - Very nice and flexible object-relational layer (with > Hibernate as another excellent OSS possibility) > Yep. You can use Hibernate outside of EJB as well. Also check out OJB: http://db.apache.org/ojb/ > > - Allows transactions of large operations that can be > rolled back (larger in scope than just DB transactions) > - Provides means for handling data security > - Helpful links to learn the basics: > http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html > (Beginner's overview) > http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html > (Tutorial for J2EE, check out Chapter 27: Method > Invocations in RosterApp for code examples) > > - Distributed objects via excellent communication systems > - Java Remote Method Invocation (RMI) allows remote access > of EJB's and transmission of complex data types and > exceptions > You can use RMI in standalone mode as well if you choose not to use EJB but= still want to make calls on remote objects or send serialized objects acro= ss the wire between virutal machines. > > - Asynchronous messaging between objects > > - Managing and deploying web services > > - Provides all the robustness of a high-quality server: > scalability, reliability (failover), extensibility, > load balancing, component hotswapping, security > >- Java a widely used language > - Lots of other OSS tools available (Ant, Struts, etc.) > Lots lots lots. Ant is a key peice of technology for managing the build an= d deployment of Java projects. The other real staples I'd say are JUnit and= XDoclet (especially if you are doing EJB). Middlegen is also very useful. > > - Many resources for developers > - Large development community: broad industry support and > credibility > One other "biggie" for Java that I'd throw in is built in support for easil= y building Internationalized applications. Struts also builds on Java's al= ready excellent ResourceBundle framework. > >Costs of J2EE: >-------------- > >- Language issues: > - Not open source at the moment > - Can be verbose > True but it's getting better. "Tiger" (J2SE 1.5.0) will have autoboxing an= d unboxing of variables so that will cut down on the amount of explicit typ= e casts that clutter up Java code. And if you can follow it, many of the A= PIs have been designed in such a way to promote method invocation chaining = which also tends to save a few key strokes here and there. I guess this is= one of the things that Groovy (http://groovy.codehaus.org/) is addressing. > > - Problems arise when trying to make different versions of Java > co-exist > unlike inconsistences in C libraries on UNIX systems? Or "dll hell" on Win= dows? I don't think you can fault Java for this ... this is pretty much acr= oss the board in computing -- regardless of claims for "backward compatibil= ity". > > - Clunkiness of UI's (perhaps attenuated by wxWidgets?) > Matter of opinion. I tend to like Swing. But perhaps you'd prefer SWT: http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html > >- Learning curve: too complex for our needs? > - Attenuated by the fact that not everyone needs to know the > entire J2EE spec, just the parts that pertain to them (JSP, EJB, > etc.) > It's a constant learning process. Certainly not going to happen overnight = but it's doable. > > - Don't need to use ALL of their technologies, just the ones we > need > This cannot be stressed enough. Don't make it more overwhelming than it al= ready is. > > - It takes a while to wade through the docs and all of the > acronyms, but it begins to make sense eventually. At least it > lacks a lot of the complex and arcane wierdness that an immature > system inevitably has. > As far as the acronyms go, they are all marketing. They simply give a name= to a piece of the functionality the API has to offer. Focus on concepts a= nd not acronyms. > >- With JBoss we would have to pay for docs beyond the tutorial (may not be >necessary for our purposes) > If you aren't going to use EJB, I'd say don't use JBoss. There has been a = bit of skeptism as of late about their fearless leader (I am not going to n= ame names here). I think the community will adapt Geronimo as the defacto = open source certified J2EE container once it gets built -- this statement i= s based on Apache's already proven track record. Technically, JBoss is great. You can also check out Resin as well which im= plements thier own version of doing CMP -- not J2EE certified but still pre= tty nice. You can check out Resin here: http://www.caucho.com/ > >Summary: J2EE is an excellent toolset that has basically everything we >need and much more, although the Java language itself has some (minor?) >issues. > >------------------------------------- > >That's what I have gathered from our research and your input. What >motivates us in all of this is the conviction that excellent business >software needs to be written in a layered, distributed, n-tier approach >with the layers clearly delineated and abstracted, and so we are seeking >the best tools that will enable us to do this. Please correct me on any >areas where you think what I have said is incorrect, or if you think there >is anything I'm overlooking. > I recognize that since you are a GNU project there may be >restrictions to using a non-Free language like Java. Java is: >"Free for development, production deployment, and redistribution" [6] >but it is NOT Open Source. There are attempts to reproduce Java as Open >Source, but as I understand it these are only at the point of Java Virtual >Machine (JVM) 1.2, and not at 1.4, which is what JBoss requires. > At this point, I'd say we (here at DM) are getting close to making >a decision as to which direction to pursue, and are leaning towards the >J2EE option, but we would welcome comments from you all. > Where is your project page again? From tpanzarella@mac.com Thu Apr 1 16:46:36 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 380D66DDD; Thu, 1 Apr 2004 16:46:36 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-45.apple.com [17.250.248.45]) by riposte.org (Postfix) with ESMTP id 934C76DD8 for ; Thu, 1 Apr 2004 16:46:04 -0600 (CST) Received: from webmail01.mac.com (webmail01-en1 [10.13.11.143]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i31Mk314000534 for ; Thu, 1 Apr 2004 14:46:03 -0800 (PST) Received: from webmail01 (localhost [127.0.0.1]) by webmail01.mac.com (8.12.6/8.12.2) with ESMTP id i31Mk3ic024796 for ; Thu, 1 Apr 2004 14:46:03 -0800 (PST) Message-ID: <10332198.1080859563575.JavaMail.tpanzarella@mac.com> Date: Thu, 01 Apr 2004 17:46:03 -0500 From: Tom Panzarella To: calendula-devel@fudosys.com X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01 version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [Calendula-devel] sorry for the spam Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: sorry for the multiple copies of my last email .. this silly .mac web interface behaves really wierd sometimes ???? sorry. t. From darrylc@fudosys.com Thu Apr 1 17:48:36 2004 Return-Path: X-Original-To: calendula-devel@fudosys.com Delivered-To: calendula-devel@riposte.org Received: from localhost (fudosys.com [12.158.191.73]) by riposte.org (Postfix) with ESMTP id 9DF216DD8 for ; Thu, 1 Apr 2004 17:48:35 -0600 (CST) Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python From: Darryl Caldwell To: caldev In-Reply-To: <12600736.1080859303026.JavaMail.tpanzarella@mac.com> References: <12600736.1080859303026.JavaMail.tpanzarella@mac.com> Content-Type: text/plain Organization: Fudo Systems Message-Id: <1080862127.1458.65.camel@pc177.vash.kcls.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Apr 2004 15:28:48 -0800 Content-Transfer-Encoding: quoted-printable Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Howdy, I found this quote on a python archive the other day: "I've written a 24,000 line Python program that's a patient=20 database/accounting program for an optometric/optician office. It uses PostgreSQL as the database to store all the data. Since most of the data processing is done by SQL commands it is plenty fast. It contains over 10,000 patients and 16,000 transactions right now. Doing many of the data tabulations would most likely be too slow if all the code were written in Python. And of course using a real database allows committing/rolling back a number of SQL statements at once and the big one for this application is allowing multiple users. I used PyGtk - used Glade to design each window. There are separate window for entering patient info, frames, professional fees, frame/lens purchase with Rx, reconciling insurance payments, tracking the cash register contents and bank deposits, etc. 41 windows in total I think." http://mail.python.org/pipermail/python-list/2004-March/210174.html I've email the developer and he said this was just a summer project to keep him busy.... The reason why I quote it is that I don't want the framework to get overly complex.=20 Three red flags keep me out of the java camp: 1. My own lack of java experience 2. I am a perl -> python convert because of the uncluttered nature of python. Java is a little noisy. 2. Java licensing. Calendula is a side project for me at this point, but it is also a necessary one because of my commitment to the NPO sector. To date, I haven't heard of another project with the same market in mind. It may only be a stepping stone to a more full bodied effort backed by the resources to make it happen. So unless someone comes up with some really compelling reasons to jump to enterprise level code, the guiding principle for me will be to keep it simple. Or as I like to say now, if you all disappear I've got to be able to do it myself. -D On Thu, 2004-04-01 at 14:41, Tom Panzarella wrote: > There is a lot of information here but I think it warrants more input. I= have to confess up front that some of what I say may be biased due to the = fact that I am primarily a Java/J2EE developer although I have reasonable e= xperience with Python -- I just really like Java. In general I agree with = what Matt is saying but I think there are more things to consider. =20 >=20 > Yes, J2EE is a more robust framework for building distributed object orie= nted applications than anything Python has to offer. I'm not trying to dis= s Python at all, I just prefer to use a hammer to bang in a nail and a fork= to eat my food unless it is soup in which case I prefer a spoon. If that = analogy makes any sense, what I'm saying is Java/J2EE IS a better choice fo= r large (define as you wish) distributed business applications than Python.= And Python is a better choice than Java for things like mailing list man= agers (ala Mailman). >=20 > I still want to stress that I think that architecture is much more import= ant than implementation language/platform. I've seen some real "train wrec= k" J2EE apps which I think are partially due to the fact that the developer= s don't fully understand what they are doing. One thing that Java/J2EE len= ds itself to (beyond all of the acronyms ... more on that later) is the eff= ective use of design patterns and a community willing to share and document= them in a standard format. For example, a popular thing today in the J2EE= community is to NOT use CMP and EJB but rather use ORM tools and framework= s (i.e. Hibernate, OJB, TopLink, etc.) to implement a persistence tier for = saving the state of POJOs (Plain old java objects) within distributed apps.= Best practices and patterns that have developed around EJB to allow for n= etwork transparency and such have also been modified to support these other= alternative frameworks. Getting specific now is way beyond the scope of t= his email. >=20 > The major issue for this project I think is two-fold: 1) skills 2) the pr= oject leader already declared Python. On the first point, if you are just = entering the J2EE world, it's not something you are going to just pick up. = If you are already a Java programmer and have some experience with design = patterns you have a better shot of breaking down the barriers to entry. I'= m not saying that the developers on this list can't do it, I'm just saying = that it will take some time to learn all the appropriate pieces and how the= y interact with eachother -- there is a lot of crap to learn. Honestly, th= e first real hurdle I see developers who come from scripting environments h= ave to get over is the fact that they actually have to compile their code, = run unit tests (well you should at least), and then deploy -- it's not just= edit the code, "C-x C-s", then hit "refresh" on your browser. >=20 > I've made some particular comments in-line with Matt's email below ..... > =20 > > > > It was mentioned by several of you a while back when there was a > >debate about which language to use that the more important thing than th= e > >specific language is the particular *architecture* we use for our progra= m: > > > >Thomas Panzarella: "Also, I think much more important that the ultimate > >language is the architecture." > > >=20 > Nice comment, who's that guy ;-) >=20 > > > >Bill Bell: "Perhaps we can agree that we will surely fail if we do a poo= r > >job of the architecture." > > >=20 > Agreed. >=20 > > > > I didn't hear much back from you all on this, and we have actually > >since been reconsidering our plans for developing these tools for Python= . > >The reconsideration comes from looking at J2EE [1], which is a free ("as > >in beer", not OSS) set of tools for Java for developing just the sort of > >app that Calendula is to be. =20 > > >=20 > A quick word on this. Java is not OSS as defined by OSI (http://www.open= source.org) but you can access the source to the the Java platform via the = Sun Community Source License which let's you do whatever you want except fo= r fork the platform. Then of course if you do build your own Java implemen= tation (for some odd reason) you will certainly have to pay license fees to= Sun to get certified as pure Java. As for J2EE, Tomcat (http://jakarta.ap= ache.org) is already the reference implementation for the Servlet/JSP/JSF p= iece of J2EE (so the source is readily available for that) and just recentl= y Sun granted Apache a "scholorship" to build Geronimo (an EJB container) w= hich will be allowed to receive J2EE certification (something that JBoss do= es not have -- totally different conversation there). It should also be no= ted that most of the "stuff" that Java/J2EE developers use on a daily basis= all comes from the OSS community and Java itself has a very vibrant OSS co= mmunity rallying around it. I can go on for days on this (especially since= I ran a discussion at Penguin Day on this exact topic) but I will spare ev= eryone the details. >=20 > For the curious, you can get the full source to the J2SE here: >=20 > http://wwws.sun.com/software/communitysource/j2se/java2//download.html >=20 >=20 > > > >J2EE vs. Python Decision > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Python > >=3D=3D=3D=3D=3D=3D > > > >Benefits of Python: > >------------------- > > > >- Language is preferrable in some ways to Java: > > - Elegant and readable >=20 > This is not fact but rather one opinion. Here is a funny interpretation = of someone who thinks just the opposite: >=20 > Full text of this blog entry can be found here: > http://www.theserverside.com/blogs/showblog.tss?id=3DGroovyReview >=20 > --- start of quote --- >=20 > Put in the simplest terms, it [Python] feels like a very annoying languag= e to me. Writing 'lambda' all of the place seems the height of silliness. T= hey can keep their 'self'. Double underscores get real old real fast - even= in just a few hours. "def"? "DEF"? WTF? I don't think I can use a language= that defines methods with a keyword "DEF" (aside: And I'm pissed that Groo= vy requires DEF, but at least its only in one specific case). >=20 > --- end of quote --- >=20 > > > >Summary: Python as a language is superior to Java in many ways,=20 > > >=20 > I'd change that line to: "Python as a language is better suited to certai= n tasks than Java." >=20 > > > > > >J2EE > >=3D=3D=3D=3D > > > >Benefits of J2EE: > >----------------- > > > >- Complete, mature toolset already in place > > - JBoss is an OSS alternative to Sun's J2EE implementation >=20 > True, but at this point I'd only suggest using JBoss if you want to use E= JB which is not necessary and sometimes undesirable in J2EE apps. EJB has = a lot of overhead to it that the marketing folk don't like to mention. But= then again that is why there is JDO and other object relational persistanc= e frameworks out there. >=20 > > > >- J2EE toolset implements many things that Python lacks: > > - Excellent client frameworks (both with Struts and the J2EE > > frameworks) > > >=20 > I will echo the praises of Struts. (Twinkle Twinkle -- inside joke for t= hose who made it to Penguine Day ;-) >=20 > > > > - Servlet approach better than the one-time executing > > scripts > > >=20 > Yep. And it's multithreaded nature make it *better* than things like Fast= CGI or mod_perl as well. >=20 > ... aside: Sorry Perl people I mean no harm, I am a big Perl / mod_perl f= an as well >=20 > > > > - Model-View-Controller concepts in both Struts and J2EE > > >=20 > True. But MVC will only be one pattern necessary for an overall sound ar= chitecture. >=20 > > > > - Enterprise Java Beans (EJB) are extremely powerful > > >=20 > True but not the only option. >=20 > > > > - (MOST IMPORTANT) Allows encapsulation of how data is > > stored and the complexities of the business logic (hides > > this from client) through a remotely accessible API > > >=20 > You don't need EJB for that .. you just need to write clean interfaces an= d apply the appropriate patterns. I think what EJB is good at is all of th= e "stuff" the container gives you: >=20 > CMP - Container managed persistence for entity beans will keep your datab= ase and distributed components' state in synch without a single line of SQL= written by you. >=20 > Network transparency - "clients" of EJBs don't have to know where the hec= k they are. You look them up in a registry (JNDI) and then call methods on= the bean's public interface. >=20 > There is more: security, transactions, etc. >=20 > > > > - Very nice and flexible object-relational layer (with > > Hibernate as another excellent OSS possibility) > > >=20 > Yep. You can use Hibernate outside of EJB as well. Also check out OJB: >=20 > http://db.apache.org/ojb/ >=20 > > > > - Allows transactions of large operations that can be > > rolled back (larger in scope than just DB transactions) > > - Provides means for handling data security > > - Helpful links to learn the basics: > > http://www.javaworld.com/javaworld/jw-10-1998/jw-10-beans.html > > (Beginner's overview) > > http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html > > (Tutorial for J2EE, check out Chapter 27: Method > > Invocations in RosterApp for code examples) > > > > - Distributed objects via excellent communication systems > > - Java Remote Method Invocation (RMI) allows remote access > > of EJB's and transmission of complex data types and > > exceptions > > >=20 > You can use RMI in standalone mode as well if you choose not to use EJB b= ut still want to make calls on remote objects or send serialized objects ac= ross the wire between virutal machines. >=20 > > > > - Asynchronous messaging between objects > > > > - Managing and deploying web services > > > > - Provides all the robustness of a high-quality server: > > scalability, reliability (failover), extensibility, > > load balancing, component hotswapping, security > > > >- Java a widely used language > > - Lots of other OSS tools available (Ant, Struts, etc.) > > >=20 > Lots lots lots. Ant is a key peice of technology for managing the build = and deployment of Java projects. The other real staples I'd say are JUnit a= nd XDoclet (especially if you are doing EJB). Middlegen is also very usefu= l. >=20 > > > > - Many resources for developers > > - Large development community: broad industry support and > > credibility > > >=20 > One other "biggie" for Java that I'd throw in is built in support for eas= ily building Internationalized applications. Struts also builds on Java's = already excellent ResourceBundle framework. >=20 > > > >Costs of J2EE: > >-------------- > > > >- Language issues: > > - Not open source at the moment > > - Can be verbose > > >=20 > True but it's getting better. "Tiger" (J2SE 1.5.0) will have autoboxing = and unboxing of variables so that will cut down on the amount of explicit t= ype casts that clutter up Java code. And if you can follow it, many of the= APIs have been designed in such a way to promote method invocation chainin= g which also tends to save a few key strokes here and there. I guess this = is one of the things that Groovy (http://groovy.codehaus.org/) is addressin= g. >=20 > > > > - Problems arise when trying to make different versions of Java > > co-exist > > >=20 > unlike inconsistences in C libraries on UNIX systems? Or "dll hell" on W= indows? I don't think you can fault Java for this ... this is pretty much a= cross the board in computing -- regardless of claims for "backward compatib= ility". >=20 > > > > - Clunkiness of UI's (perhaps attenuated by wxWidgets?) > > >=20 > Matter of opinion. I tend to like Swing. But perhaps you'd prefer SWT: >=20 > http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html >=20 > > > >- Learning curve: too complex for our needs? > > - Attenuated by the fact that not everyone needs to know the > > entire J2EE spec, just the parts that pertain to them (JSP, EJB, > > etc.) > > >=20 > It's a constant learning process. Certainly not going to happen overnigh= t but it's doable. >=20 >=20 > > > > - Don't need to use ALL of their technologies, just the ones we > > need > > >=20 > This cannot be stressed enough. Don't make it more overwhelming than it = already is. >=20 > > > > - It takes a while to wade through the docs and all of the > > acronyms, but it begins to make sense eventually. At least it > > lacks a lot of the complex and arcane wierdness that an immature > > system inevitably has. > > >=20 > As far as the acronyms go, they are all marketing. They simply give a na= me to a piece of the functionality the API has to offer. Focus on concepts= and not acronyms. >=20 > > > >- With JBoss we would have to pay for docs beyond the tutorial (may not = be > >necessary for our purposes) > > >=20 > If you aren't going to use EJB, I'd say don't use JBoss. There has been = a bit of skeptism as of late about their fearless leader (I am not going to= name names here). I think the community will adapt Geronimo as the defact= o open source certified J2EE container once it gets built -- this statement= is based on Apache's already proven track record. >=20 > Technically, JBoss is great. You can also check out Resin as well which = implements thier own version of doing CMP -- not J2EE certified but still p= retty nice. >=20 > You can check out Resin here: http://www.caucho.com/ >=20 > > > >Summary: J2EE is an excellent toolset that has basically everything we > >need and much more, although the Java language itself has some (minor?) > >issues. > > > >------------------------------------- > > > >That's what I have gathered from our research and your input. What > >motivates us in all of this is the conviction that excellent business > >software needs to be written in a layered, distributed, n-tier approach > >with the layers clearly delineated and abstracted, and so we are seeking > >the best tools that will enable us to do this. Please correct me on any > >areas where you think what I have said is incorrect, or if you think the= re > >is anything I'm overlooking. > > I recognize that since you are a GNU project there may be > >restrictions to using a non-Free language like Java. Java is: > >"Free for development, production deployment, and redistribution" [6] > >but it is NOT Open Source. There are attempts to reproduce Java as Open > >Source, but as I understand it these are only at the point of Java Virtu= al > >Machine (JVM) 1.2, and not at 1.4, which is what JBoss requires. > > At this point, I'd say we (here at DM) are getting close to making > >a decision as to which direction to pursue, and are leaning towards the > >J2EE option, but we would welcome comments from you all. > > >=20 > Where is your project page again? >=20 >=20 > _______________________________________________ > Calendula-devel mailing list > Calendula-devel@fudosys.com > http://list.fudosys.com/mailman/listinfo/calendula-devel --=20 Darryl Caldwell darrylc@fudosys.com Fudo Systems www.fudosys.com 206/567-5802 "Free Your Computers!" From tpanzarella@mac.com Thu Apr 1 18:45:02 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 369726DDC; Thu, 1 Apr 2004 18:45:02 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-87.apple.com [17.250.248.87]) by riposte.org (Postfix) with ESMTP id 5E7A56DD8 for ; Thu, 1 Apr 2004 18:44:30 -0600 (CST) Received: from webmail22-en1.mac.com (webmail22-en1 [10.13.10.122]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i320iTEM013959 for ; Thu, 1 Apr 2004 16:44:29 -0800 (PST) Received: from webmail22 (localhost.mac.com [127.0.0.1]) by webmail22-en1.mac.com (8.12.6/8.12.6) with ESMTP id i320iTpc009763 for ; Thu, 1 Apr 2004 16:44:29 -0800 (PST) Message-ID: <999158.1080866669080.JavaMail.tpanzarella@mac.com> Date: Thu, 01 Apr 2004 19:44:29 -0500 From: Tom Panzarella To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10 version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: > >The reason why I quote it is that I don't want the framework to get >overly complex. > The point of frameworks is to keep code maintainable and simple. Whether you subscribe to an exsiting framework or build your own, once the project is large enough, ultimately you are going to use one. Zope is a framework upon which other frameworks are built until ultimately one of them is the really easy way to do task X. CMF on top of Zope and Plone on top of that == "really easy web site CMS system". The same applies in Java: Struts takes the Servlet/JSP framework to another level of simplicity and managability, RMI makes it easy to invoke methods on remote objects, other J2EE based frameworks do the same thing for other facets of distributing computing. > >Three red flags keep me out of the java camp: > >1. My own lack of java experience > Very valid reasoning. > >2. I am a perl -> python convert because of the uncluttered nature of >python. Java is a little noisy. > I'll be the first to admit that Java is a bit verbose but I don't think anyone can argue that it is not "clean". Also, Java's verbosity is due to the fact that it is a statically typed compiled language. You have to dot your "i's" and cross your "t's". > >2. Java licensing. > How would Java licensing affect Calendula? The licensing of Java effects people like IBM, BEA, Oracle and the like. As far as "we" are concerned it's free beer and we can give away our code under whatever licensing scheme we would like, even the GPL. Think of Java as an operating system and Calendula as the application that rides on top it -- I doubt the Python version of Calendula will need to make kernel modifications to windows or Linux, right? So who cares that we can't change the public interface of and redistribute the Java platform??? > >It may only be a stepping stone to a more full bodied effort backed by >the resources to make it happen. So unless someone comes up with some >really compelling reasons to jump to enterprise level code, > I just want to clear up one thing and this is not targeted at Darryl but rather "the industry" in general. The word "enterprise" is so over used and it's essentailly marketing-ese for "distributed computing" - multiple programs interacting with eachother over a network. I'm assuming a full multi-user install of Calendula will be able to be marketed as: "enterprise python code" or some other buzz word friendly way to drive downloads. > > the guiding >principle for me will be to keep it simple. Or as I like to say now, if >you all disappear I've got to be able to do it myself. > Very smart man. I vote Python! Also, I think you are doing a great job Darryl and I'm doing exactly what I said I wouldn't do up front ... I'm involved in defending Java on an otherwise Python slanted list when really what this is about is results for NGOs not the technical merits of languages, platforms, frameworks, etc. If I were the architect, I'd choose J2EE, but I'm not. At the same time I do think that a Python system can be architected to scale and work too. Let's do it. t. From bill-bell@bill-bell.hamilton.on.ca Thu Apr 1 18:58:34 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 8EC1E6DDC; Thu, 1 Apr 2004 18:58:34 -0600 (CST) Received: from smaug.vex.net (smaug.vex.net [66.246.136.211]) by riposte.org (Postfix) with ESMTP id DCAF56DD8 for ; Thu, 1 Apr 2004 18:58:02 -0600 (CST) Received: from default (Hamilton-ppp106789.sympatico.ca [216.209.129.6]) by smaug.vex.net (Postfix) with ESMTP id BE3FD35295 for ; Thu, 1 Apr 2004 19:57:45 -0500 (EST) From: "Bill Bell" Organization: Bill Bell To: Calendula-devel@fudosys.com Date: Thu, 01 Apr 2004 19:57:01 -0500 Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python Reply-To: bill-bell@bill-bell.hamilton.on.ca Message-ID: <406C740D.17317.336F1913@localhost> Priority: normal In-reply-to: <5204302.1080859297732.JavaMail.tpanzarella@mac.com> X-mailer: Pegasus Mail for Windows (v4.12a) X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: Mail message body Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: On 1 Apr 2004 at 17:41, Tom Panzarella wrote: > Yes, J2EE is a more robust framework for building distributed object > oriented applications than anything Python has to offer. Wouldn't be a bit surprised, given what I've seen and experienced in the Python world. > I'm not trying to diss Python at all, I just prefer to use a hammer to > bang in a nail and a fork to eat my food unless it is soup in which > case I prefer a spoon. If that analogy makes any sense, what I'm > saying is Java/J2EE IS a better choice ... I've probably said this before. However, if I'm going to remain as a member of this team you'd all better get used to repetition. ;o) To me this debate is partly about whether we should use a woolly mammoth to crack a walnut. It seems to me that there are numerous issues to explore, and that we should do that work in the simplest possible setting. Which is probably neither Zope nor J2EE. > One thing that Java/J2EE lends itself to ... is the effective use of > design patterns and a community willing to share and document them in a > standard format. Since this is, to some extent and unfortunately, about Java/J2EE vs Python, I really need to mention that much of the discussion on the "main" Python list has often been couched in terms of design patterns, admittedly without including some of the patterns supported by J2EE. Patterns can be economically and readably expressed in Python code, as Tom might very well agree. (Standard doc formats?: Oh, well, one can't have everything.) > .. if you are just entering the J2EE world, it's not something you are > going to just pick up. Likewise, Zope. There would be lots of preparatory work ahead for some of us, either way. > ... the first real hurdle I see developers who come from scripting > environments have to get over is the fact that they actually have to > compile their code, run unit tests ... I daresay that a good few developers that use compiled languages are really just "scripting". AFAIK this issue has nothing much to do with whether the project chooses Python or J2EE or Java. It has to do with the project team's expectations. We all know that Python now comes with unit testing "out of the box", right? Why not simply stipulate that--no matter the architecture or language--we'll all follow that discipline--among others. (And, incidentally, as a Python bigot, I should probably not mention that the Python module was adapted from Beck's for Java.) Bill From pattonm@dm.org Fri Apr 2 15:06:17 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 5409A6DDC; Fri, 2 Apr 2004 15:06:17 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id EC4226DD8 for ; Fri, 2 Apr 2004 15:05:44 -0600 (CST) Received: by mail.dm.org (Postfix, from userid 510) id 48FD2C0609; Fri, 2 Apr 2004 16:05:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.dm.org (Postfix) with ESMTP id 29AC1164B41; Fri, 2 Apr 2004 16:05:44 -0500 (EST) Date: Fri, 2 Apr 2004 16:05:44 -0500 (EST) From: Matthew Patton To: Tom Panzarella Cc: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python In-Reply-To: <999158.1080866669080.JavaMail.tpanzarella@mac.com> Message-ID: References: <999158.1080866669080.JavaMail.tpanzarella@mac.com> X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Thank you for your excellent insights, Tom. It is good to hear from someone who has real experience with J2EE. Your pointers and clarifications were a big help. I think one of the things that was most helpful was your clarification about the debate itself: we are not debating whether Java is better than Python, but rather we are trying to figure out which tool would be best for the job at hand. Bill has stated his preference: > To me this debate is partly about whether we should use a woolly mammoth > to crack a walnut. It seems to me that there are numerous issues to > explore, and that we should do that work in the simplest possible > setting. > > Which is probably neither Zope nor J2EE. And yet, I think that I agree more with what you were saying, Tom: > The point of frameworks is to keep code maintainable and simple. > Whether you subscribe to an exsiting framework or build your own, once > the project is large enough, ultimately you are going to use one...The > same applies in Java: Struts takes the Servlet/JSP framework to another > level of simplicity and managability, RMI makes it easy to invoke > methods on remote objects, other J2EE based frameworks do the same thing > for other facets of distributing computing. I have experience writing small-medium sized applications without frameworks or with very simple frameworks, and there are several problems that develop as the project grows: 1. It eventually becomes a maintenance nightmare because so many low-level tasks are being done explicitly every time (SQL calls, passing data from page to page, data conversions, transactions, etc.) 2. Because every chunk of code has its own arcane nuances, it is a ton of work to extend the program to do new things, and it would be a huge task to write a module for it. My point is that if Calendula is going to escape getting bloated when it reaches a certain size, you will need good tools. Furthermore, it seems that J2EE, although it has a certain amount of work tied to it up front in order to learn it, nevertheless it promises to keep things much simpler and more maintainable because the code that we write lacks all of the low-level baggage it would carry if it was written without the tools. Thus I do not think J2EE is like using a Woolly Mammoth to crack a walnut (that is, unless you do not plan to have Calendula grow very big). Rather, it is a tool to help us write clean, well-organized, long-lasting code that we can really build on instead of nasty spaghetti code that we're constantly fighting against and re-writing. And yet, what you say below intrigues me, Tom: > Very smart man. I vote Python! > > ...If I were the architect, I'd choose J2EE, but I'm not. > At the same time I do think that a Python system can be architected to > scale and work too. Let's do it. > Although you personally would prefer J2EE, you seem to see Python as an option. Why is that? What architecture design patterns are you thinking of? What tools are you thinking of that are already in existence for Python that will enable us to leap right into writing Calendula? From the research I've done of the tools available for Python, I don't see how we can expect to write a distributed, extensible, multi-layered multi-user application in Python. Unless you intend to make Calendula a simple, lightweight application for a specific limited purpose (fundraising), then I think we're going to need something like J2EE. But I'd be glad to be proved wrong. Thanks very much for your thoughts! Matt From tpanzarella@mac.com Sat Apr 3 15:27:16 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 9DAD76DDC; Sat, 3 Apr 2004 15:27:16 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-84.apple.com [17.250.248.84]) by riposte.org (Postfix) with ESMTP id 8D3766DD8 for ; Sat, 3 Apr 2004 15:26:44 -0600 (CST) Received: from webmail04.mac.com (webmail04-en1 [10.13.11.146]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i33LQfaw000206; Sat, 3 Apr 2004 13:26:42 -0800 (PST) Received: from webmail04 (localhost [127.0.0.1]) by webmail04.mac.com (8.12.6/8.12.2) with ESMTP id i33LQfx1006895; Sat, 3 Apr 2004 13:26:41 -0800 (PST) Message-ID: <2985822.1081027601440.JavaMail.tpanzarella@mac.com> Date: Sat, 03 Apr 2004 16:26:41 -0500 From: Tom Panzarella To: Matthew Patton Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python Cc: calendula-devel@fudosys.com X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: >> ...If I were the architect, I'd choose J2EE, but I'm not. >> At the same time I do think that a Python system can be architected to >> scale and work too. Let's do it. >> > >Although you personally would prefer J2EE, you seem to see Python as an >option. Why is that? What architecture design patterns are you thinking >of? What tools are you thinking of that are already in existence for >Python that will enable us to leap right into writing Calendula? > From the research I've done of the tools available for Python, I >don't see how we can expect to write a distributed, extensible, >multi-layered multi-user application in Python. Unless you intend to make >Calendula a simple, lightweight application for a specific limited purpose >(fundraising), then I think we're going to need something like J2EE. But >I'd be glad to be proved wrong. Thanks very much for your thoughts! > In a former position I held at a scientific computing company / software ve= ndor, I worked in the middleware division where we (me and 10+ other softwa= re engineers) were charged with building (not buying) an application server= to support our organization's entire suite of internet based applications = which were written in disparate languages: some Java, some perl, some C++ c= gi's (no joke!), etc. We had to engineer and distill out the common set of= infrastrucure services all of these applications needed in order to make t= he individual apps "thinner" -- and to enable quicker time-to-market with n= ew products. As we were working out the architecture for our middleware se= rver we found that certain languages were better for a particular job than = others. So we decided to build out our app server in a very modular fashio= n where each core component "spoke" to another component via a "web service= s" type architecture -- we didn't use any "standard" protocol like SOAP bec= ause it was too "chatty" to handle the immense amount of remote calls we wo= uld have to send over the wire, but the point is, we worked out our own wir= e-level protocol that was encoded in a language independent manner to enabl= e reasonable RPC/RMI type communication between our server components. The= result was that some folks implemented their piece in Java, others did it = in mod_perl, and others in C. Our "public interfaces" were very clean so, w= e had all this stuff talking to eachother and it was great. We didn't real= ly care about "portability" because we weren't selling the middleware to an= yone (the apps were sold on a subscription basis in an ASP type of environm= ent) and we knew our deployment environment intimately (Solaris 8 across bo= ard). It was fun to build from an engineering perspective and it really pr= oved to be finanically rewarding for the company.=20=20 That was version 1. As additional requirements kept rolling in for new app= s to ride on top of our server, refactorings to existing apps, low-level pe= rformance issues, more stringent security concerns, etc. we began to get "o= verloaded" since we had to build all of this stuff in ourselves. Again, fr= om an engineering perspective it was great fun, but we also had the dreaded= deadlines and we simply couldn't keep pace with building, testing, and rel= easing our code to satisfy our marketing and sales department -- they were = selling features to clients that hadn't even made it to our desks as a requ= irement yet (probably not all that uncommon). Anyway, we kept supporting o= ur server as "dot" releases to the 1.x tree but we ultimately chose to push= back on the application developers to port their code over to Java so we c= ould implement the 2.x tree using J2EE so we could focus on our specific bu= siness needs and not the plumbing. Ultimately I moved on from that company but I periodically check out the li= ve environments where the applications live to see how the middleware is ho= lding up (since I'm a former engineer with them, I know ways to determine w= hat is running what ;-) I proud to say they still haven't deployed the J2E= E version yet which means some variation of our 1.x code is still running o= ut there. My point is that it is possible to build well designed modular code to work= in a distributed environement that is not J2EE or .Net and be successful. = But when you do, you are opened up a whole new set of challenges -- not on= ly do you have to build the business specific logic but you will mostly spe= nd your time writing "plumbing" or infrastructure code (i.e. building *your= * framework) -- persistence mechanisms, database connection pools and query= brokers, auth* subsystems, communications protocols, etc etc etc. This type of thing reminds me of a quote from Henry Spencer (http://www.lys= ator.liu.se/c/henry/) about the UNIX operating system, he says: "Those who do not understand UNIX are condemned to reinvent it, poorly." Could we port that over to J2EE? t. From tpanzarella@mac.com Sat Apr 3 15:28:14 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id F303C6DDF; Sat, 3 Apr 2004 15:28:13 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-45.apple.com [17.250.248.45]) by riposte.org (Postfix) with ESMTP id 2FF1D6DD8 for ; Sat, 3 Apr 2004 15:27:41 -0600 (CST) Received: from webmail04.mac.com (webmail04-en1 [10.13.11.146]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i33LRe14009130 for ; Sat, 3 Apr 2004 13:27:40 -0800 (PST) Received: from webmail04 (localhost [127.0.0.1]) by webmail04.mac.com (8.12.6/8.12.2) with ESMTP id i33LRex1006908 for ; Sat, 3 Apr 2004 13:27:40 -0800 (PST) Message-ID: <7610568.1081027660409.JavaMail.tpanzarella@mac.com> Date: Sat, 03 Apr 2004 16:27:40 -0500 From: Tom Panzarella To: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: >> ...If I were the architect, I'd choose J2EE, but I'm not. >> At the same time I do think that a Python system can be architected to >> scale and work too. Let's do it. >> > >Although you personally would prefer J2EE, you seem to see Python as an >option. Why is that? What architecture design patterns are you thinking >of? What tools are you thinking of that are already in existence for >Python that will enable us to leap right into writing Calendula? > From the research I've done of the tools available for Python, I >don't see how we can expect to write a distributed, extensible, >multi-layered multi-user application in Python. Unless you intend to make >Calendula a simple, lightweight application for a specific limited purpose >(fundraising), then I think we're going to need something like J2EE. But >I'd be glad to be proved wrong. Thanks very much for your thoughts! > In a former position I held at a scientific computing company / software ve= ndor, I worked in the middleware division where we (me and 10+ other softwa= re engineers) were charged with building (not buying) an application server= to support our organization's entire suite of internet based applications = which were written in disparate languages: some Java, some perl, some C++ c= gi's (no joke!), etc. We had to engineer and distill out the common set of= infrastrucure services all of these applications needed in order to make t= he individual apps "thinner" -- and to enable quicker time-to-market with n= ew products. As we were working out the architecture for our middleware se= rver we found that certain languages were better for a particular job than = others. So we decided to build out our app server in a very modular fashio= n where each core component "spoke" to another component via a "web service= s" type architecture -- we didn't use any "standard" protocol like SOAP bec= ause it was too "chatty" to handle the immense amount of remote calls we wo= uld have to send over the wire, but the point is, we worked out our own wir= e-level protocol that was encoded in a language independent manner to enabl= e reasonable RPC/RMI type communication between our server components. The= result was that some folks implemented their piece in Java, others did it = in mod_perl, and others in C. Our "public interfaces" were very clean so, w= e had all this stuff talking to eachother and it was great. We didn't real= ly care about "portability" because we weren't selling the middleware to an= yone (the apps were sold on a subscription basis in an ASP type of environm= ent) and we knew our deployment environment intimately (Solaris 8 across bo= ard). It was fun to build from an engineering perspective and it really pr= oved to be finanically rewarding for the company.=20=20 That was version 1. As additional requirements kept rolling in for new app= s to ride on top of our server, refactorings to existing apps, low-level pe= rformance issues, more stringent security concerns, etc. we began to get "o= verloaded" since we had to build all of this stuff in ourselves. Again, fr= om an engineering perspective it was great fun, but we also had the dreaded= deadlines and we simply couldn't keep pace with building, testing, and rel= easing our code to satisfy our marketing and sales department -- they were = selling features to clients that hadn't even made it to our desks as a requ= irement yet (probably not all that uncommon). Anyway, we kept supporting o= ur server as "dot" releases to the 1.x tree but we ultimately chose to push= back on the application developers to port their code over to Java so we c= ould implement the 2.x tree using J2EE so we could focus on our specific bu= siness needs and not the plumbing. Ultimately I moved on from that company but I periodically check out the li= ve environments where the applications live to see how the middleware is ho= lding up (since I'm a former engineer with them, I know ways to determine w= hat is running what ;-) I proud to say they still haven't deployed the J2E= E version yet which means some variation of our 1.x code is still running o= ut there. My point is that it is possible to build well designed modular code to work= in a distributed environement that is not J2EE or .Net and be successful. = But when you do, you are opened up a whole new set of challenges -- not on= ly do you have to build the business specific logic but you will mostly spe= nd your time writing "plumbing" or infrastructure code (i.e. building *your= * framework) -- persistence mechanisms, database connection pools and query= brokers, auth* subsystems, communications protocols, etc etc etc. This type of thing reminds me of a quote from Henry Spencer (http://www.lys= ator.liu.se/c/henry/) about the UNIX operating system, he says: "Those who do not understand UNIX are condemned to reinvent it, poorly." Could we port that over to J2EE? t. From maasj@dm.org Sat Apr 3 20:24:35 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 9197E6DDC; Sat, 3 Apr 2004 20:24:35 -0600 (CST) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id D71CC6DD8 for ; Sat, 3 Apr 2004 20:24:03 -0600 (CST) Received: from gondor.maasj.dm.org (gondor.maasj.dm.org [192.168.11.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dm.org (Postfix) with ESMTP id EC4572351F8; Sat, 3 Apr 2004 21:23:55 -0500 (EST) Date: Sat, 3 Apr 2004 21:23:53 -0500 (EST) From: Jason Maas To: Tom Panzarella Cc: calendula-devel@fudosys.com Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python In-Reply-To: <2985822.1081027601440.JavaMail.tpanzarella@mac.com> Message-ID: References: <2985822.1081027601440.JavaMail.tpanzarella@mac.com> X-DiscipleMakers-MailScanner: Found to be clean X-MailScanner-From: maasj@dm.org X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi Tom, Thanks for sharing your real-world J2EE experience with us, it's quite helpful! On Sat, 3 Apr 2004, Tom Panzarella wrote: >My point is that it is possible to build well designed modular code to >work in a distributed environement that is not J2EE or .Net and be >successful. Well said. =) >"Those who do not understand UNIX are condemned to reinvent it, poorly." I have that quote memorized and it's been funny (& sad) to watch M$ stumble their way down the path to a poor man's unix. =) But anyway, let's get back to the point at hand... >Could we port that over to J2EE? I'm not sure I understand your point here. Are you saying here that by predominantly using Python the Calendula project is destined to poorly reinvent J2EE? Also, I didn't totally understand your response to Matt's question (paraphrased): "if you think J2EE is the best way to go, why are you so gung-ho about Python?" Are you saying that it's because you enjoy the challenge of "doing it all yourself"? Or is it because J2EE is what you do "at work" and Python is what you do "for fun"? I'm a bit confused. -Jason From tpanzarella@mac.com Sat Apr 3 21:42:41 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 2DACC6DDC; Sat, 3 Apr 2004 21:42:41 -0600 (CST) Received: from smtpout.mac.com (A17-250-248-83.apple.com [17.250.248.83]) by riposte.org (Postfix) with ESMTP id 622816DD8 for ; Sat, 3 Apr 2004 21:42:09 -0600 (CST) Received: from webmail10.mac.com (webmail10-en1 [10.13.10.112]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i343g7at012846 for ; Sat, 3 Apr 2004 19:42:07 -0800 (PST) Received: from webmail10 (localhost [127.0.0.1]) by webmail10.mac.com (8.12.6/8.12.2) with ESMTP id i343g7OM023423 for ; Sat, 3 Apr 2004 19:42:07 -0800 (PST) Message-ID: <12295491.1081050127052.JavaMail.tpanzarella@mac.com> Date: Sat, 03 Apr 2004 22:42:07 -0500 From: Tom Panzarella To: calendula-devel@fudosys.com Subject: Fwd: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10 version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: From: Tom Panzarella TO: Jason Maas CC: Date: Sat Apr 03, 2004 10:40:33 PM EST Subject: Re: [Calendula-devel] Architecture Thoughts: J2EE vs Python > >let's get back to the point at hand... > >>Could we port that over to J2EE? > >I'm not sure I understand your point here. Are you saying here that by >predominantly using Python the Calendula project is destined to poorly >reinvent J2EE? > No. What I am saying is that J2EE has already addressed many of the issue that Calendula will have to face. Starting from "scratch" is hard. J2EE is nothing but a set of API specifications that addresses all of the "known" issues that are common to distributed apps. The implementors of the J2EE spec (be it BEA, IBM, or JBoss) have already built the plumbing necessary for application developers to focus on their application specific needs. I don't know of anything in the Python world that is nearly as comprehensive or robust to even compare ... So.... if the implementation of Calendula is in Python, many of the same concerns already addressed by J2EE will have to be considered by the Calendula developers. > >Also, I didn't totally understand your response to Matt's question >(paraphrased): "if you think J2EE is the best way to go, why are you >so gung-ho about Python?" > Because the project manager, Darryl, has declared it his choice. He is very smart in doing this. He is comfortable with Python and it's capabilities. If everyone else were to "quit" tomorrow, he would still have a workable code base in his lap. There is much more to picking a platform and architecture than pure technical merits ... one must take a pragmatic view when heading up a project such as Calendula. > >Are you saying that it's because you enjoy the >challenge of "doing it all yourself"? > No, but it can be fun -- but I'm not interested in Calendula to "reinvent the wheel", I am attracted to this project because it will help NGOs ... a business sector that I hold very close to my heart. > >Or is it because J2EE is what >you do "at work" > Partially ... although, even though I work primarily in a J2EE environment, I still love Java programming -- the innovation in the Java community is unrivaled compared to what I have seen elsewhere ... again, just an opinion. > >and Python is what you do "for fun"? I'm a bit confused. > Good question. I actually haven't done anything in Python that I would consider *real* in a very long time. I use Python (and Perl and /bin/bash ... depending on my mood) to do the little "hacks" that I need on a day-to-day basis -- because that is what I am good at using those languages for. Currently, what I am doing for "fun" is Groovy (http://groovy.codehaus.org/) programming. t. From pattonm@dm.org Tue Apr 27 09:40:24 2004 Return-Path: X-Original-To: calendula-devel@riposte.org Delivered-To: calendula-devel@riposte.org Received: by riposte.org (Postfix, from userid 612) id 0CF826DDC; Tue, 27 Apr 2004 09:40:24 -0500 (CDT) Received: from mail.dm.org (noah.dm.org [216.169.168.27]) by riposte.org (Postfix) with ESMTP id 8586C6DD8 for ; Tue, 27 Apr 2004 09:40:21 -0500 (CDT) Received: by mail.dm.org (Postfix, from userid 510) id 7DC3FC0630; Tue, 27 Apr 2004 10:40:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.dm.org (Postfix) with ESMTP id 4CC3B164B4B for ; Tue, 27 Apr 2004 10:40:20 -0400 (EDT) Date: Tue, 27 Apr 2004 10:40:20 -0400 (EDT) From: Matthew Patton To: calendula-devel@fudosys.com Message-ID: X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on slice.riposte.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Level: X-Sanitizer: Advosys mail filter MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [Calendula-devel] Final decision Sender: calendula-devel-admin@fudosys.com Errors-To: calendula-devel-admin@fudosys.com X-BeenThere: calendula-devel@fudosys.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: , List-Id: Development Discussion for Calendula (Fundraising System) List-Post: List-Help: List-Subscribe: , List-Archive: Hi Darryl et al, Just wanted to let you all know of the decision of us four here at DiscpleMakers to go ahead with J2EE development of a suite of software for non-profits. The project URL is: http://daniel.sf.net/ Since J2EE provides all of the low-level architecture solutions we need (instead of us having to reinvent them in Python), we felt it was the best way to go. We're sorry it didn't work out to partner with all of you since we share very similar visions, and we appreciate the stimulating discussions we've had with you all. Thanks, Matt ______________________________________________________________ Matthew Patton pattonm@dm.org DiscipleMakers Headquarters: (814)234-7975 x32