>1. James's database structure is very simple. The core of James has the
>potential to use 2 unrelated tables. One for a user repository and one for
>a message spool repository. The structure of these tables are very simple.
=> JDBC
>3. We need a lot of control over how data is returned for performance
>reasons.
=> JDBC
> Two big limitations we are experiencing with Town (that I believe
>we would have with Turbine and other abstraction layers) is the inability to
>return parts of a ResultSet and to get streamed access to binary data.
=> JDBC
>I believe with documentation, this could be overcome. Then the only thing
>we need is a JDBC connection pool code,
What is connection pool code?
The choice is probably between JDBC/RDMS/SQL and some sort of object
database or conceivably something like LDAP although that probably
wouldn't work. RDMS is very well-worked out and MySQL, for example,
works very, very well. It's just that everyone seems to hate writing
SQL statements. I don't and would be happy to look at raw SQL if
it's posted.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
