On Wed, 2003-10-29 at 02:50, Bryce Harrington wrote:
Based on our discussions so far, it looks like the invariants might be:
- Full SVG compliance
And CSS2 and XML, too, of course.
- Core coded in C/C++
Yes.
- Gtk-compliant user interface
GNOME HIG-compliant, really, as Nathan pointed out.
- Extensible using various scripting languages
The scripts should be able to act as first-class citizens of the core.
I think more generally, it should be a major design goal to make "plug-ins" first-class citizens.
( It should be understood that at the beginning, this means plugin breakage will be frequent until the core really APIs stabilize. Not much worse than the situation with Linux kernel modules, IMO. )
Being able to say "no" to a feature in the core is easier if development outside the core and runtime installation is easy and carries few disadvantages. This is one of the primary drivers behind Firebird's success, IMO.
So, basically I would want to aim (long-term) for a Firebird-like approach to functionality and extensions/scripts.
- Open, community-oriented development processes
Absolutely.
- Baseline is the Sodipodi 0.32 codebase
Well, Hydra. There's an appreciable delta between 0.32 and HEAD/Hydra in places, as I recall.
- Strives to use commonly available libraries
Mmm, again with Nathan on this one. I don't think it should be a goal.
I think using libraries on the "edges" (i.e. I/O related stuff, like Gtk and libxml/libcroco parsers, and Cairo) carries a lot of advantages.
However, most applications I've seen that use external libraries in their core (i.e. their data model) suffer as a result. Often the extra shims needed to make a library do exactly what's needed harm maintainability and runtime efficiency.
I think we should keep our "core" stuff completely in-house -- in practice I think that means the XML tree, object tree, the canvas widget, and the application framework used by extensions.
In general we need to evaluate libraries very carefully based on maturity and how well they directly meet our needs.
If we need to use a new library for something, we also need to ask whether it's worth doing at all in the main codebase -- maybe it would be better as an extension.
Establishing them as invariants allows us all to admit and agree that C and C++ suck, and lets us get down to coding in them anyway. ;-)
Yep.
-mental