Re: more gnome 2 proposal

[Havoc Pennington <hp redhat com>]

Alex Graveley <alex ximian com> writes: 
> Arguments about a single module being easier to build are not the point.
> Dependencies being easier and development more streamlined is also not
> the point. They are secondary bonuses gained through the implementation
> of the real purpose: large scale componentization of Gnome.
> 
> What this means is that we would not building a huge monolithic
> unmaintainable beast. Your arguments do not apply as they are not
> thinking in this mindset. We would be building components that rely on
> eachother heavily and should be in the same package to make development
> sane.  

Whoa - to me the whole point of components is to allow lots of
separately-maintained small components, and get rid of huge shared
library packages. Components (from Perl modules to Delphi components
to Windows controls) normally allow this. Combined with a proper IDE,
developers don't even have to know which DLL's exist.

Componentization of GNOME can go on with each component being done
totally separately - that's what components are for!  If we finish the
components and someday want to merge them into one big package, then
OK, with a proper component system the merger would be 100%
app-developer-transparent.

> What being a componentized framework means is: 
> 
>     Dependencies become simple interface-driven mechanisms.
> 
>     Replacing buggy or bad ideas (Imlib, GtkXmHtml) becomes simple as
>     applications will simply be unable to find those deprecated
>     components, or will find interface compatible wrappers to their
>     replacements.
> 
>     New implementations of core components can be rolled in to the
>     system by third parties. 
> 
>     Use of developmental implementations become transparent to the
>     system and applications.

This utopia seems to assert that designing the right interface 
isn't any part of the work of writing a library, while I would say
that it's a solid 50% or more of the work. And most evolution or
enhancement of a library requires interface changes.
 
This is one reason you want things broken up; so that you can do new
interfaces that replace the old ones, without having the one big
package grow without bound, and dead/no-longer-supported interfaces
can be dropped out of the package with high granularity as they become
obsolete.

> Wrt complexity of the tree, the fact that everything would 1)
> component-based and b) integrated, means that we can come up with a sane
> tree layout that makes sense for all of the core modules. Not just one
> that makes sense for bonobo, one for gnome-libs, one for gconf... all
> that make sense for the individual package but when taken with all the
> other packages in the system add to a confusing non-uniform mess.

They add up to a sane properly modular architecture that takes
advantage of componentization. ;-)

But "componentization" is probably too vague an issue to discuss - I'd
rather see a specific list of specific interfaces which would be
included in GNOME 2.

Havoc