fantasai wrote:
You're making our life harder than it already is. :-)
>
> 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? That would make three
categories since it's already split between Web developers and Mozilla
developers.
> 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 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.
It would be interesting to have the opinion of a js person on this.
>
> Have a look at layout's outdated docs; it's documenting the
> software's internals--stuff that doesn't apply to Gecko's
> interaction with other software. I'm not saying that APIs
> should be separated from internal docs by a high-level
> categorization, but notice that it's not just documentation
> of APIs you've put in tech/.
See my reply above.
>
> "Technology", as I understand from various discussions here,
> is the brick and mortar of applications; "technologies" are
> combined to form an application just as brick and mortar are
> combined to build a house.
>
> So, how does it hold up in the real world?
>
From the positive answers I have received, pretty well.
>
> 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.
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.
Only one "component" of the editor is reused in a large scale in the
rest of Mozilla-the-software: the text widget. 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.
>
> If the structure of /dev cannot handle this gracefully, then it
> needs rework. (One option is to flatten the projects in the URI
> and categorize with HTML. Then projects can easily change
> categorization and even be in two groups at once.)
>
The flattening is and has always been a posibility, but imho it is not
the solution we are looking for.
>
>>Here is my definition of "product"
>>"A product is based on, and implements a mix of technologies to form a
>>usable "software" on its own. Different products can have different
>>implementations for the same technologies." For instance, XBL is a
>>technology, but Mozilla implements it and combines it with other
>>technologies to form a usable software.
>>
>
> The word you're looking for here is "application", not "product".
> http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?application+program
>
> As I see it, Gecko is also a product. It is not, however, an application.
>
Yes, maybe an application is a better word than product. Both still fit
in the /projects directory, and in my opinion they are very much synonym.
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. I'd call it a "concept", more
than a real entity. People working on the different components that make
the rendering engine (and what _is_ the rendering engine? layout? style
system? do we include the dom?) do not care whether they are working on
Gecko or not. I think Gecko should not be represented in the site by
more than an index to all the technologies used to render a site (and
we'll probably argue as to what is used to render a site).
>
>>- User Interface docs (specs, ...)
>>
> User Interface specs go with their respective application's directory.
> It's the software's interface, is it not?
>
Sounds good to me. Bye bye /dev/ui then?
I hope I sounded convincing ;-)
-Fabian.
