Fabian Guisset wrote:
>
> fantasai wrote:
>...
> > You're mixing up two things here. One is the API. The other
> > is the software that implements it.
>
> I agree. But in the mozilla.org website, we will want to have both the
> documentation of the XUL interface _and_ the documentation of the
> implementation of XUL by our software. Unless you suggest that we
> separate those docs in two different categories?
Not really. The former would be
<http://mozilla.org/develop/mozilla/xul/reference/>, and the latter
would be most of the rest of the stuff in the
<http://mozilla.org/develop/mozilla/xul/> hierarchy.
> That would make three
> categories since it's already split between Web developers and Mozilla
> developers.
Last I checked, no-one was seriously proposing that Web developers
should use XUL for anything. That's unlikely to change, unless Microsoft
decides to implement it.
>...
> JavaScript in an interesting example. In Mozilla we have two
> implementations of it: Rhino and spidermonkey. One is written in Java,
> the other in C. The current website separates them into
> mozilla.org/spidermonkey and mozilla.org/rhino, linked from
> mozilla.org/js. I argue that neither spidermonkey nor rhino are
> products. They are technologies, created to be embedded in larger
> structures to form a usable software. Now maybe we could have
> /dev/tech/js which links to /dev/tech/spidermonkey and
> /dev/tech/rhino.
The URIs in /develop/web/ should be generic, as the technologies to
which they refer may change in the future. For example, three years ago
<http://mozilla.org/develop/web/scripting/> would have been about
writing basic stuff on a Web page with JavaScript. Now, that URI would
house Fabian's DOM documentation as well as a Javascript reference. In
three years time, the DOM might be replaced with something else, but the
URI for the same task -- doing scripting of Web pages -- should stay the
same. (This is why www.w3.org uses /MarkUp/ instead of /HTML/, /XHTML/,
or /XML/.)
For /develop/mozilla/, however, this is not necessary, since if a
codebase is replaced then (a) there is legitimate interest in both the
new and old stuff, and (b) there is not likely to be any overlap between
the two. If, for example, OJI was replaced by some new-fangled Java
embedding system, they would have completely different documentation. So
<http://mozilla.org/develop/mozilla/oji/> could hang around to be
accessed by those doing legacy development on (or maintenance of) OJI,
without being disturbed by the new
<http://mozilla.org/develop/mozilla/jfu/> stuff.
There is no need to cause gratuitous linkrot, of course; we shouldn't be
constantly changing <http://mozilla.org/develop/mozilla/mailnews/> to
<http://mozilla.org/develop/mozilla/mail/> or
<http://mozilla.org/develop/mozilla/hermes/> or whatever it happens to
be called this month. But if the entire current mail/news codebase was
discarded, then any replacement would have a different URI so as not to
interfere with the legacy docs.
>...
> > Place editor.
> > http://mozilla.org/editor/
> > No arbitrary decisions here--defend your placement with logic.
> > Notice that the editor can be embedded and is used to implement
> > text widgets--but it can also be used as a standalone application
> > with an XUL-based UI.
>
> The editor cannot be separated from the browser and mailnews at the
> moment. However several people have raised the necessity of being
> future-compatible. It is my opinion that in the future a "software"
> like the editor may become a product on its own.
Precisely what I warned of before. Things which are `technologies' now
may become `products' in the future, and vice versa.
> Only one "component" of the editor is reused in a large scale in the
> rest of Mozilla-the-software: the text widget.
Nope. The editor's layout engine is also used in the browser. So is the
style system. The plain-text editor is also used in mail/news, and so is
the HTML editor.
> If we wanted to follow
> the definitions very strictly, we would have to separate the text
> widget from the editor. Which doesn't look like a good idea. On the
> other hand, the editor uses a lot of technologies: XUL, JS, XBL, DOM,
> and the whole slew of lower-level technologies like XPCOM. So in that
> respect, even though it currently isn't a product, it fits very nicely
> in the /projects directory that Gerv proposed.
I propose renaming /projects to
/dumpingbucketforstuffwhichwecouldntdecidewasaproductoratechnology.
It's not the first time I've said this, but ... Given enough hype,
anything is a project. Anything. A /projects directory is meaningless.
>...
> We haven't talked about Gecko yet. Unfortunately Gecko is a very badly
> defined entity of Mozilla. It is a set of technologies interacting
> together, yet it is not usable on its own.
So file a bug, `Rewrite Gecko so that it fits in the Web site'. :-)
>...
> I hope I sounded convincing ;-)
>...
You're about where I was a year ago. About six months ago, after lots of
helpful badgering from Fantasai, I realized that trying to separate
products and technologies was more trouble than it was worth.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
