The main framework is TurboGears, so a fair amount of Luca's architecture comes directly from TurboGears stack: Javascript+Mochikit for client-side trickery and AJAX; Kid for HTML templating; CherryPy as controller framework, and SQLObject as database-neutral model.
It was decided long ago (from 2000) that the base development language would be Python, since it has been the best interpreted language around. The next question was which Web framework to use (or go solo and create a mini-framework from scratch). The framework should be free, unobtrusive, "Pythonic" and have a fair learning curve.
Before TurboGears, Zope was considered for Luca. It has really being pushed by the Python community as the "Python on Rails". Zope proved to be too bureucractic (too much typing for too little work) and difficult to learn. However, some specific Zope components e.g. ZODB are really of great value and could be reconsidered for Luca adoption in the future.
SQL access will employ TurboGears' SQLObject component. However, some aspects of Luca development may contradict SQLObject mantras.
SQLObject encourages to deny the SQL nature of the underlying database, as it were a necessary evil eventually washed out by a truly OO database. For exemple, SQLObject does not encourage joins, it rather encourages table trasversal in loops, as they were memory-based, or file-based like Clipper DBFs. IMHO this is a step backwards.
In the other hand, we could go one step further and use ZODB instead of normal databases. While ZODB is good and I felt tempted to try it, it would add another dependency for the Luca project: while SQL databases are everywhere, ZODB audience is still small, and mostly centered in Plone users (Plone is built on top of Zope). Also, I already have a working accounting system (CTB) which is based on SQL, and modeling the new database over SQL makes my life easier: I begin with an almost-ready model, and migration from CTB to Luca will be easier.
So Luca will stay with SQLObject and an underlying SQL database. All standard features for database integrity are put into use: primary keys, constraints and foreign keys. Most OO people hate this, because "all business logic must belong to the application!". I see those SQL features as a safety net against erroneous data; of course the business logic duplicates most those checks, in order to return more friendly error messages etc., but business logic may have bugs.
Luca will not use triggers or stored procedures. These features tend to be the most unportable across databases; SQL (including dialects like PL/SQL) is a bad language for business rules coding; and this level of business intelligence really belongs to the application server -- in particular when it runs "near" the database (i.e. in the same machine, or in the same fast LAN).
Stored procedures are certainly useful when an open-ended number of applications access the same database, and DBA must enforce business rules for all of them in one shot. The trade-off is, once a database software is chosen, it is difficult to migrate. Luca's use case is the opposite: a single application that is meant to be database-neutral.
Luca's pet database is MySQL with InnoDB backend, because it supports all desired SQL features, like foreign keys, and it is handy for me since I already run it for other applications. Since SQLObject is database-neutral, and will do our best not to circumvent SQLObject, the system should stay portable across databases. We will test this in practice for most popular free databases.
TurboGears' identity features are employed by Luca.
We have seen systems that deliver an abstract XML and a XSLT ruleset for the client to transform into a report (and the result was ugly!). We see no point in gratitious client-side processing; it is simpler for the system and for the user to transmit a plain (X)HTML with a proper CSS.
The only requirement for the user will be to run a browser with sufficient CSS and Javascript implementations. Javascript tends to be a bigger portability problem, since it does not degrade gracefully as CSS. The main testing browser will be Mozilla Firefox, with limited testing rounds in IE. We will not have much time to make extensive cross-browser tests (help out!), but Mochikit evens out most cross-browser Javascript incompatibilities. (That means the our Javascript code must use Mochikit as much as possible in order to take advantage of its portability).
A long desired feature of Luca is the ability to support UIs other than Web e.g. text mode. In some environments, in particular when fast data entry is demanded, GUI or text mode are more productive.
While no alternative UI is foreseen in the Roadmap, CherryPy controller makes it relatively easy to support, since all controller methods can be exported as JSON remote calls (that are also employed in AJAX communication). Of course, Luca development must keep a healthy separation between core business logic and Web glue code, so future non-Web applications just call the business logic functions.
One alternative (off-line) UI is already bundled with Luca: LucaMobile. This application works on Series 60 smartphones and Nokia Maemo devices. It already uses JSON RPC calls.