[Project_owners] A MozDev Mission Statement?

Axel Hecht axel at pike.org
Tue Sep 16 20:23:04 EDT 2003


GuruJ wrote:

<...>
> 
> THEY don't care about having access to PyXPCOM, PlXPCOM or Jslib.  But 
> WE do!

I don't. See, it's pretty tricky.

> THEY don't need documentation more in-depth than how to navigate the 
> built-in menu system.  But WE desperately do!

If you want to talk about docs, please use a different thread.

> Application Suite fans have different requirements (common UI, 
> Composer/Chatzilla/Venkman, all tools available as a single download) to 
> MozillaFirebird users (speed, simplicity, small size).  That's why the 
> fork exists!
> 
> Similarly, our needs are different from both MozillaClassic and 
> MozillaFirebird.  There can only be one logical conclusion to all this ...
> 
> Ladies and Gentlemen, I give you:  MadBird.
> 
> If we, as a community, *truly* believe that Mozilla has a future as a 
> development environment, then *we* must make it one.  Here's a sample 
> roadmap:
> 
> 1.  Contact Mozilla.org project leads and canvass the idea.  Get 
> quasi-'official' status (eg. link on front page).
> 2.  Fork Mozilla 1.4.1.  MadBird lives!

Veto. You may wann create a branch. But not a fork. For most of your 
things, you don't even need a branch, but just a build guy.

> 3.  Give trusted MozDev developers super-approver status, and set up a 
> (hopefully simple) approval chain.
> 4.  Link in PyXPCOM, PlXPCOM (if it's ready for primetime), and JsLib 
> and enable by default.

I glanced over PlXPCOM, I didn't see a DOM0 package. From what I can 
tell, there is no interface flattening either. Not sure about CAPS.
There doesn't seem to be DOMCI, too. And there's not mailing list.

Pete, what's the status of the old archives?

PyPXCOM has no pages up at all. Well, just a whole bunch of empty 
templates. There are no cvs sources, either, so it's impossible to say 
what that code does or does not do.

Ready for primetime is different.

> 5.  Hell, let's even add in SVG and MNG support -- I'm sure they would 
> be killer tools for developers, even if they are still incomplete.
> 
> (Now things get tricky...)
> 6.  Get a working GRE core.  Document in painstaking detail the process 
> for creating standalone apps that link to this core.

  find . -name \*.cpp | xargs grep -l MOZ_THUNDERBIRD
./docshell/base/nsWebShell.cpp
handling of clicking links that need to be handled by thunderbird 
instead of an external browser, AFAICT.

./xpfe/appshell/src/nsAppShellService.cpp
commandline handling hack

./mailnews/base/src/nsMessengerBootstrap.cpp
./mailnews/base/src/nsMessengerWinIntegration.cpp
./mailnews/mapi/mapihook/src/nsMapiRegistryUtils.cpp
./mailnews/mime/src/mimei.cpp
./mailnews/news/src/nsNntpService.cpp
didn't bother investigating.

find . -name \*.cpp | xargs grep -l MOZ_PHOENIX
./extensions/cookie/nsCookieService.cpp
./dom/src/base/nsGlobalWindow.cpp
different cookie prefs

./xpfe/browser/src/nsBrowserInstance.cpp
./xpfe/components/bookmarks/src/nsBookmarksService.cpp
./xpfe/components/build/nsModule.cpp
different components for firebird

./browser/components/bookmarks/src/nsBookmarksService.cpp
copy of above

./toolkit/components/history/src/nsGlobalHistory.cpp
funny hack, no idea.

The stuff beneath xpfe, dom, extensions, docshell, toolkit is undefined 
behaviour for a GRE. I wonder if timeless filed bugs on these yet.
Who (that question came up before) has the guts to decide what to do on 
these?

> 7.  Identify what 90% of Mozilla developers would need to easily create 
> standalone applications (easy GUI-building toolkit, File I/O, Text 
> Editor (vanilla and/or rich text), etc).  If the techniques needed to 
> use these technologies are too advanced, create wrappers (eg. JSLib) 
> that make these technologies easily accessible.

A platform independent apprunner, so that you can actually kick off your 
app without writing native code. Working on it.

Note that this is the one item that is actually on-topic for this 
thread. Identify what is really needed by Mozilla developers.

> (Down the track...)
> 8.  Highlight core inadequacies in the current Mozilla toolkit. Examples 
> might be:
>     - RDF functionality only 80% complete.

Do me a favour and drop that silly number.  The only relevant numbers 
are bug numbers.
At least my rdf trees show 100%, not 80% ;-).

>     - Components and interfaces aren't frozen.

That may have something to do with, hrm, should I say 80%?

>     - No JavaScript events for PNG.
> 9.  Fix these inadequacies.
> 
> If the changes we make are positive, there's a good chance they will be 
> incorporated back into the tree.  And if not, at least we're doing 
> something positive towards creating the cross-platform application 
> programming environment that we all want.
> 
> Okay, that's me done.  Who wants to shoot the argument down in flames?

All in all, nothing mentioned here can't be done on the trunk. At least 
in times when it isn't frozen. Most of the things mentioned here 
*should* be done on the trunk. Get your editors out, grab bugs and start 
making the world a better place.

Axel



More information about the Project_owners mailing list