Re: Don't bloat Gnome-libs, bloat Gtk+/Glib
- From: Michael Meeks <michael ximian com>
- To: Havoc Pennington <hp redhat com>
- Cc: Owen Taylor <otaylor redhat com>, gnome-hackers gnome org
- Subject: Re: Don't bloat Gnome-libs, bloat Gtk+/Glib
- Date: Tue, 13 Mar 2001 06:09:33 -0500 (EST)
Hi,
On 12 Mar 2001, Havoc Pennington wrote:
> If you want a standard that lots of projects will use, it needs to be
> clearly separated organizationally and historically from any one
> project. You also need everyone to feel involved in that standard.
Certainly you need to get everyone involved in the standardization
effort. What most people remember is the BetaMax / VHS type situations.
Often this is not how I see the standardization process working. I see it
happening like this:
* A problem exists
* A load of people solve it slightly differently
eg. XP-COM/Bonobo/UNO
* People realize fragmentation is bad for them
a) People sit down, make compromises, and standardize on common
interfaces, and implementations
b) People slowly migrate their propriatory implementations towards
the standard
Of course, a corrolary of a) is that the final spec. tends to be
horribly bloated with lots of corner cases :-). Luckily issue b) doesn't
worry me much - we don't need slow migration we just need some level of
compatibility, we can cut and choose between Free software
implementations.
> So typically it's necessary to create a new codebase or new
> specification in order to achieve standardization.
A specification yes, a new code base sounds extremely wasteful,
creating a standard itself is painful enough without having to discard
umpteen working implementations.
> So I have in the past considered the issue of a cross-project system
> abstraction, but have not considered GLib a viable candidate for
> that. Maybe this helps you understand the current direction of GLib.
Yes, fair enough it was a throwaway comment really, but one I am
indeed interested in. I think the greater the degree of co-operation,
shared code, and inter-operability in the Free software community the
better - the best application code really will win then without artificial
barriers.
Regards,
Michael.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]