Mozilla code structure

* Boris Zbarsky <[email protected]> wrote:

<snip>

> Put another way, I do have data that shows that generic system libraries 
> use more memory than custom-written code (that provides just the small 
> subset of functionality that the app needs). 

Depends on how fat these libs are. Which ones do you compare exactly ?

> > Right. Then try to fix these libraries
> 
> Some of the library maintainers aren't very interested in accepting 
> help. 

If there's no other way, join OSS-QM and make a fork ;-P
I already did this w/ a bunch of packages. 

> msvcrt was mentioned, for example. 

Acutally, I don't care about M$ crap. I've left that stupid platform
several years ago. They've been on an good path w/ NT-4.x, but w/ 5.x 
everything started degeneration again. 

BTW: there's cygwin.

> But there are plenty of examples on Linux too, usually under the guise 
> of "that's not what it's designed to do" or "it's good enough to run 
> GNOME" or some such.

Yeah, in GNOME world, there are enough stupid folks, too. I remember 
some really strange discussions several years ago in the gtk list ;-o
If I had an personal interest in gtk, there would already be an really
cleaned and trimmed down up 3x ;-p

> > (within their jobs) or tell the world about the broken crap.
> 
> The world knows.  Now what?  The world knowing doesn't make broken code run.

Let these folks be responsible for their own crap again and don't try
to heal the whole world ;-P

> > If you try to work around evrybody else's crap, you'll never get finished.
> 
> And if you don't, you'll never work right and hence never ship.  Sounds 
> like we should all pack up and go home.

No. Every package has it's project. That project (only that project!) is
responsible for it. If the upstream doesn't listen - fork off.

> > And once one of the bugs is fixed, you have to take care of disabling or
> > removing the workaround (since it will most likely break then, again)
> 
> You're making the assumption that the behavior in question is (1) a bug 
> and (2) will be fixed.  

Of course. Evrything else is useless.

> If the behavior is mandated by some standard (whether broken or not), 
> it won't be considered a bug.  See POSIX.  

If some behaviour is intended, but doesn't fit your need, you've chosen
the wrong interface.

Maybe some bit rude, but this axiom makes your job easier (as long as 
you're consequent).

> Even if it's considered a bug there's no guarantee that it'll be 
> fixed quickly, or at all.  

It's opensource - you can fix it by yourself.

> See the Apache default MIME type story, for example.

Apache folks sometimes tend to be stupid, too. I've coded enough there 
to know that.

> > The trick in cross-platform development is not caring about every single
> > difference, but abstraction: build upon interfaces which are DEFINED to
> > be platform independent (and maybe help implementing these within their
> > dedicated projects).
> 
> Then you need to implement those abstractions.  

Of course, but only once and for all. And if you do it really cleanly,
evryone can *rely* on that interface and doesn't have to care about 
platform specific issues - they're simply out of scope. 

> > In other words: strict modularity.
> 
> NSPR is quite modular in this sense, yes?

Not really. It's still one big fat thing. I personally wouldn't use it 
for my projects. I could imaging using some parts of it - if they were 
dedicated modules.

> > If you need new semantics: build a new, dedicated library and *import*
> > (NOT include) it into your main project.
> 
> Yes.  See NSPR.

For a short term (any only within moz), NSPR is an good approach. 
But it doesn't go far enough. It should be split off.

> > Platform dependend exceptions (workarounds) are the worst approach:
> > For an large application, it makes it unmaintainable, and all that
> > work is very redundant.
> 
> Hey, we agree on something!

Great :)

> > For a *short* time, it's okay to work around other's bugs. But this has
> > to be *strictly limited*
> 
> Define "short"? 

One release cycle ?

> And then the fact that most people don't upgrade their OS the 
> instant an upgrade is available.

Their fault - not yours.
Everyone should do his job, not evryone else's.

> > Then it might be broken. The OS vendor is responsible for providing 
> > an working OS - no one else.
> 
> That doesn't solve the pernicious problem of trying to build software 
> that will run on said OS (all of them, to be exact).

Shit happens. Tell the users about the crappy systems.
Either they learn or they run into trouble.

Again: you can't heal the whole world.

> > I don't see any reason why that new allocator should be limited to
> > the only one client package.
> 
> Who ever argued that it would be?

Actually, don't know. But if I look at the mozilla codebase, 
that's my first idea ;-P

> > Some time ago, I already asked for the reasons. For those few cases
> > I got an answer, it were just people not wanting to wait for some
> > bugs get fixed.
> 
> For severe enough bugs (security bugs, e.g.) this might be a reasonable 
> tradeoff.

So, the responsible people don't take my reports serious. That matches
the response to my posts in several lists. I just remember some discussion
@ dev-build, where some guy burns his resources in coding an new build
system for moz, which should handle mozilla's crappy code structure 
instead of joining me cleaning up this crap. It starts w/ the need of 
multi-stage builds (IMHO, an really rediculous concept)

> > Ah, so you also feel responsible for certain people's broken our 
> > outdated systems ? Oh, that's interesting.
> 
> When "certain people" is "100% of our userbase"... yes, maybe we feel we 
> need to deal with the situation somehow.

Then, you take responsibility for other folk's crap. Seems you've got
quite unlimited resources ;-P

> > Maybe you also feel responsible for my dirty dishes and like to 
> > come around for cleaning the up ? ;-P
> 
> Perhaps not, but I see no problem with selling food that won't stick to 
> your dishes if I know that all my customers have no running water to 
> clean dishes with.

Maybe you've got some major misdesign in your product ? ;-P


To get off this meta-discussion, back to conceret issues:
The code structure should be cleaned up - split the whole things 
into several parts with *CLEAN* interfaces.

Kicking off all the 3rd-party stuff should be the first step.
Then let's see, what mozilla code could go to its own libs.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------