[Freecats-Dev] language / database / integration (cont.)

[Henri Chorand]

> I fully agree with comments 1 & 3.

I don't want to impose choices as far as development tools are concerned.

Java remains a possible option, even though, personally, I don't favor it
due to performance issues (and I also do NOT know it).

We might gain a lot by trying to compare what comes out from writing a given
module in a couple of languages/tools (at least IF we can provide
near-accurate figures) in terms of development effort and performance.

That said, until many more developers are in, we also risk to loose
efficiency if we scatter things too much.

Therefore, even though I really don't want to impose choices, I still favor
the Tcl/Tk approach for building together the parts, if only because it
should be more easy to glue together modules written in whatever one likes.
So, this personal approach does not rule Java out at all (nor Python, nor
whatever Tcl interfaces with).

One last "grand-pa" style advice: before coding, let's carefully build a
modular architecture, after which we'll decide what to code/reuse/adapt with
which language.

> I don't know enough about the berkeley DB to have an opinion there.

(...)

>  From all the gossip I've heard, one of the fastest databases out
> there (and speed really is an issue in this application) is berkely DB.
> http://www.sleepycat.com/products/index.shtml. It's a proprietary
> system but comes with the source code and is issued under a
> licence that bears an uncanny resemblance to some other GPL-
> compatible licences (you only pay if you don't want to use it in a
> closed-source application).

Doesn't this rule it out for us?

> Many (APIs) boil down to just two commands: "connect" and
> "send query."

Sure, we need better (and we deserve better).

I tried to define what we need in terms of server API in my draft
specifications document. As it did not receive any feed-back from senior
developers yet, I can't tell whether it's half-baked or a bit better
already. My main critic would be that I did not think enough about the
connected/non-connected mode options and their implications.

As far as I see things for databases, the "least effort" we should target is
somewhere between a complex product which we still have to learn and adapt,
or a more basic stuff over which we have to build more features.

> 3. Integration

See above, about why Tcl/Tk for assembling pieces of code together.

I saw that somebody already built a Tcl/Tk install procedure module, which
only needs to be localized (and I believe we translators can provide that).

A "newbie" fully packaged installation and setup procedure is included in
the requirements, for good reason.


Regards,

Henri