I have delevoped quite a few 'small' systems now using PostgreSQL and Perl CGi's and I have found the development cycle very fast compared to the more traditional methods (my main job is COBOL programming). However, I have, even on these small systens, found times when this interface too limiting. With the size of this proposed system I can see that at some point this will happen. I see this as one more reason for using PostgreSQL. As will as the native C libraries and the various perl modules (I prefer DBI) for accessing PostgreSQL, there are ODBC drivers for it. This opens it up then for practically any development environment, even using Access as the front end - although I found this far too much effort. Delphi apps work brillient with it. I use the built in Delphi database movetable to port data to/from PostgreSQL with ease. I find the �50,000 costs suggested in another branch of this thread to be a bit excessive. Surely there would be enough support for a normal open-source project. Once the data model has been agreed, and some basic goals specified, there should be no problem with dishing out code jobs the suitable volunteers. I would imagine there could be a working prototype will within the 7 months mentined. Gary On Sunday 29 April 2001 8:33 pm, Robert J Gautier wrote:
However, I wouldn't exclude the possibility of writing special clients if functionality required it (and I'd write them in Tcl/Tk, for portability).
I would argue strongly that special clients should not be required or provided. Once you provide them, then there is a temptation to implement functionality in them that is not available in the web clients, and I believe that in this day and age there is very little that cannot be done with cleverly designed web pages and server side software.
I agree with both your arguments against special purpose clients: those are excellent reasons to try to avoid them. However, until we know the requirements we can't say there won't be some strong requirement that can't be implemented with a web browser, and if that were to happen, I'd want to solve the problem with Tcl/Tk (in preference to Java, by the way).
I'd happily start working the details out based on an 'Any Browser' constraint (see www.anybrowser.org) for the user interface.
Aiming everything at a browser might unnecessarily contrain user interfaces too: for example, we might more easily do a 'drag-n-drop' interface in Tk than as a web page, and (IMHO) Tcl/Tk is lighter weight than Java for this sort of thing. I can also do simpler editing interfaces with Tcl/Tk (no need to refresh a page when I edit or create an item), using the same HTTP transactions that a clunky web interface would use.
Bob Gautier Ateb Limited
-- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000