281386 - The Mozilla platform really needs a developer package

Status: RESOLVED INVALID

(Firefox Build System :: General, enhancement)

Description

[David Teller [:Yoric] - still alive but not very active]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2)

Currently, if a developer attempts to write a cross-platform XPCom-based
extension based on a specific version of the Mozilla Platform, the only portable
method seems to create a subdirectory of mozilla's source tree, adapt a
Makefile.in, spend many hours reading numerous howtos and installing additional
tools and only then, starting compilation. This approach is very time-consuming,
extremely frustrating and requires many skills which one shouldn't need just to
write/port/contribute/test a few lines of C++ (or associated
JavaScript/XUL/DTD). I believe that this is also a major hinderance to the
adoption of the Mozilla platform as a viable development platform.


Gecko SDK is a step in the right direction but it contains only Frozen APIs,
although non-trivial features require non-frozen APIs, even if this means having
to change a few lines of code or the logic of a few modules from time to time
when non-frozen APIs change. For instance, to develop and test a protocol
handler, it is important to have access to nsIStandardURL, nsMimeTypes,
nsIMIMEService, nsNetCID.h, nsIFileStreams and nsEscape.h -- and that's just one
of the classes of one of the modules of the extension we're working on. Many
distributions of Linux provide packages to remedy this problem (mozilla-dev and
nspr-dev for DEB-based distributions, mozilla-devel and nspr-devel for RPM-based
ones, Gentoo does not seem to need it, nor BSDs). Roughly, these packages
contain gecko-sdk, a mozilla-config utility and most of the interfaces and
headers generated during the compilation of the Mozilla suite. It seems that
there are no similar packages for other Unix-based OSes (including Mac OS X) nor
for Windows.

I therefore suggest the creation of such a cross-platform developer package. I
believe that such a package, along with XULRunner, could make the Mozilla
Platform a real contender in the game of cross-platform development. And, in
particular, it would make my life very much easier.

Reproducible: Always

Steps to Reproduce:
1. Write simple XPCom component under Linux
2. Sit in front of Windows station / sit in front of non-Linux Unix station.
3. Try to compile Mozilla.
4. Bang head on walls.
5. Return to step 3.
Actual Results:  
1. Sore head.
2. An almost irresistible impulse to perform an unholy ritual to either get my
code to work or curse to hell whoever is somehow responsible for it not working.
3. Ritual was eventually not performed as the responsible was quite likely me.
4. Impulse is still present.

Expected Results:  
1. Write trivial Makefile.
2. Compile.
3. Test.

Comment 1

[Frank Wein [:mcsmurf]]

To get an overview what's in such a package (for example mozilla-dev on Debian),
take a look at
http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=mozilla-dev&version=unstable&arch=i386&page=1&number=all
(attention, long list!)

Comment 2

[Benjamin Smedberg]

Many of the files listed in mcsmurf's link should definitely *not* be part of a
developer package. I am open to the possibility of including some non-frozen
interfaces if they are clearly marked, but most of the .h files listed are
absolutely useless (or worse).

Comment 3

[David Teller [:Yoric] - still alive but not very active]

Well, maybe not everything is necessary or acceptable but I can think of plenty
of headers which are. Currently, I assume that the packagers of mozilla-dev
proceed by automatically collecting all the headers. Maybe some kind of
annotation system could be interesting to help determine which headers are
relatively safe and which are considered unhealthy/dangerous ?

Possibly
* I assume all the headers & interfaces already included in gecko-sdk are
already considered safe
* a few utility headers (nsEscape.h, nsQuickSort.h, nsString.h...)
* maybe all the interfaces from XPIDLSRC and the corresponding headers should be
considered safe unless otherwise specified ?

And, in the best of worlds, if a header/interface is considered unhealthy, the
reason why it is so should be documented.

Comment 4

[Darin Fisher]

I think we should focus our efforts on improving the set of frozen interfaces
instead of trying to document stuff that is in flux and will likely never be
frozen.  If URL escaping is useful, then we should provide a frozen interface to
our URL escaping code, etc.

Comment 5

[David Teller [:Yoric] - still alive but not very active]

Well, Open-Source projects have never been about waiting for a stable version of
the libraries before we can start coding, has it ?

Regarding the documentation, a simple

/**
 * @status NONPUBLIC should only be instanciated by nsSomeComponent, as it calls
nsSomeCallBack() as side effect
 */

should be sufficient.

Comment 6

[Brendan Eich [:brendan]]

We already have doc-comment conventions (@status
(EXPERIMENTAL|UNDER_REVIEW|FROZEN) -- see
http://www.mozilla.org/projects/embedding/Mozilla_API_freezing.html and bug
48726), but we are *not* going to label all non-public headers with @status
PRIVATE.  That's busywork that sends the wrong message, and will never be
maintained as new private interfaces are added.

Wishing for an interface to be frozen or otherwise usable as if it were won't
keep that interface from breaking when you least expect it.

People should stop assuming things they wish for, and play by the
long-established rules.  If you need a specific frozen API, propose something
and we'll work together to come up with a supportable interface.  Just assuming
or demanding won't cut it.

/be

Comment 7

[David Teller [:Yoric] - still alive but not very active]

Well, considering the number of unfrozen things (honest questions: is the
installer API frozen ? are the XULs frozen enough to be safely overlayed ?
sarcasm: are RDF APIs frozen ? is XULRunner even lukewarm ?) any medium-sized
Mozilla Platform project is bound to depend on plenty of unfrozen APIs and I
don't see this being solved before 2 years. 

(At which point, according to my cynical evaluation, the Mozilla Platform &
Suite will have extreme trouble keeping up with Microsoft's .Net & IE7, in the
first place. But yes, that's out of topic.)

So, if you feel that the best way of handling the situation is to make sure many
things become frozen in the near future, please, by all means, go for it. How
should I format 'bugs' to ask for the freezing of an interface ?

Just keep in mind that the current situation is quite difficult for all of us
who are trying to make cross-platform 'big extensions'/XUL applications.

Comment 8

[Brendan Eich [:brendan]]

Yoric: bugzilla is not the place for this exchange, but if you think the Mozilla
suite is some kind of alternative to IE, all I can say is: ever heard of Firefox?

XULRunner and libxul will be done much sooner than two years; some time this
year at the current level of hacking, sooner as we staff up.

I suggest you take your requests for frozen APIs to the newsgroups.

/be