Fabian Guisset wrote:
>
> fantasai wrote:
>
> You're making our life harder than it already is. :-)
I'm not trying to, though.
> >
> > 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?
I wrote further down that I am not suggesting such a thing;
I merely observed that your written definition does not match
your examples.
For the record, I'm neither against nor for any specific /dev
structure proposal. I am against an ill-defined URI structure;
that is, one which is ambiguous and/or does not gracefully
accept the content we need to place in it.
> > JavaScript is an
> > interface, but it's useless if you don't have a js engine.
>
> 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 products. To twist "product" into your definition
requires far too much mutilation, IMHO.
If you don't believe me, go ask ActiveState whether they
consider their Perl interpreter a product or not
<http://www.activestate.com> or Iona whether they consider
their CORBA implementation to be a product or not.
<http://www.iona.com/>
Of course, there's always the dictionary :)
http://www.dictionary.com/cgi-bin/dict.pl?term=product
> > Here's a challenge:
> >
> > 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.
>
> Only one "component" of the editor is reused in a large scale in the
> rest of Mozilla-the-software: the text widget.
The scale of its use is irrelevant. It's the nature of its
use we're interested in here. How often something is used
has no effect on what it /is/--and the URI hierarchy should
be defined by what things essentially are rather than by such
ephemeral characteristics as popularity.
> If we wanted to follow the definitions very strictly, we would have
> to separate the text widget from the editor.
The editor docs from the Composer docs.
BTW, the editor is, as mpt pointed out once in an IRC
discussion, also used in the mail/news composer.
> 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.
Everything is built on top of "technologies", Fabian. The
style system builds on XPCOM--is it now a "project"? XSLT
uses the DOM--should we group it, too, with the "projects"?
You cannot use that as a discriminator because it applies
to every software development project hosted by mozilla.org.
