That's the plan with this graph... I'm using a tool (graphviz) that is
never going to give us a pretty picture, but here's basically the course
of action I want to take:
1) from the completed graph, start asking questions like "Why does xpcom
depend on necko?"
1a) as we find wierd dependencies, we fix the bogus ones in a sensible
manner by fixing the code - this may involve API changes, abstraction of
certain components, etc.
2) as we break dependencies, the graph should start to unravel into
groups of components that are inexorably linked. I like to refer to
these components as being "strongly connected" - in the graph they will
appear as a group of components that are part of a cycle, and all
components that the cycle is dependent on. In the previous graph, you
can see that string, xpcom, and uconv are all part of a cycle, and they
are dependent on mozreg. I call this group of strongly connected
components a "cluster". Currently mozilla is composed of probably 2-3
clusters, but I expect we can unravel it to at least 8 or 9.
3) Certain groups of clusters will be useful to consumers of xpcom, to
embeddors, and so forth. Well-defined groups of clusters will provide us
with packaging information that embeddors can use, depending on their
level of interest. (i.e. some embeddors might want a networking layer,
some might not)
A side effect might be some nice engineering diagrams at least showing a
little about the architecture of our systems.
Alec
Jon Smirl wrote:
> I've also been trying to map some this out by hand. I've come to the
> conclusion that everything in Mozilla is dependent on everything else. It
> would really be nice to sort these dependencies out into a more hierarchical
> tree allowing a smaller, more componentized Mozilla to be built.
>
> For example I just started with the gfx directory. I figured the basic
> graphics routines would be pretty isolated from the rest of the system but
> they aren't. They are dependent on Widget, View, Gfx2, Intl, LibUtil,
> LibPr0n, Netwerk and more.
>
> There must be a way to sort this out in a more layered manner. The tangled
> compoenent web is probably the single hardest issue for me to deal with when
> trying to work on Mozilla.
> --
>
>
> Jon Smirl
> [EMAIL PROTECTED]
>
>
>
>
