www.mozilla.org URI structure

Gervase Markham

unread,

Sep 3, 2001, 5:48:15 PM9/3/01

to

This is the current proposal for the URI structure of the new Zope-based
www.mozilla.org. Comments welcome. Discussion time period: 1 week, after
which we'll roll the comments in and that'll be that.

Principles of URI design:

A URI is a -permanent identifier-. It should be constant.

The URI structure "should reflect the >>best logical
organization<< of the documents on the server by
exploiting its hierarchical nature."

Thus, there should be "a place for everything and
everything in its place".

The structure should create a coherent organization of
the site's content.

It must be extensible and highly forwards-compatible.

Proposed URI Structure:

Notes on the URI Proposal:

The creation of /software/mozilla instead of just assuming
/software for mozilla prepares mozilla.org for the
possibility of splitting the application into separate
releases. It also provides a place for any other software
released by mozilla.org.

/contribute details *how* to contribute--code, docs, qa, etc.
Much of http://mozilla.org/quality/ goes under /contribute/
qa/. Testcases can go in their respective /dev directories.

Sections under /contribute link to Get Involved pages for
individual projects. E.g. BugAThon may be linked from
/contribute/qa, but it exists in layout's directory under
/dev.

Splitting away /dev/web allows web-developer content to be
more free-form. Web developers aren't going to view the
separation of, say, the JS engine, the DOM, and the style
system as sharply as we do. Docs for web developers are
integrated. Docs for Mozilla developers are more separated;
they are both organized and written differently, and the
focus and purpose of their content also differs. This is
why web-developer documentation should not be spliced into
the various development directories. However, /dev/web can
still link to docs in those directories!

The use of dates for publications organization ensures a
coherent structure regardless of topic--which is more easily
addressed by an HTML page with descriptions anyway. Articles
will frequently appear in more specific directories rather
than in the /news hierarchy, but will always be linked from
the month's index page.

Key URLs from the old site, such as /MPL and /releases, will
be handled by redirects. Current key URLs are:\
/MPL and friends
/credits.html
/releases and friends/
/mailnews/start.html
/mozorg.html
/news.rdf
Anything that's ever been coded into a release, so:
/quality/help/bug-form.html
/quality/bug-writing-guidelines.html
/quality/smoketests/

Gerv

Ian Hickson

unread,

Sep 3, 2001, 8:46:36 PM9/3/01

to Gervase Markham, mozilla-do...@mozilla.org

On Mon, 3 Sep 2001, Gervase Markham wrote:
>
> Proposed URI Structure:

Overall looks great!

I think community/ should be its own top level directory, emphasising its
importance. Encouraging community involvement is one of the main things
missing on www.mozilla.org right now. The community/ section should
explain how to join mailing lists and IRC, and should cater for whatever
projects are being worked on (e.g. Bugzilla, Mozilla, Mozbot) whereas
about/ should, by its nature, be pretty static information about the
mozilla.org organisation itself.

IMHO.

> | |
> | |--history/ - a history of mozilla.org
> | |
> | |--mission/ - mission
> | | http://mozilla.org/mission.html
> | |
> | |--people/ - who we are
> | | http://mozilla.org/about.html
> | |
> | |--sponsors/ - sponsors
> | |
> | |--credits/ - http://mozilla.org/credits.html

Also colophon/, explaining how the site itself was created.

> |
> |--contribute/ - How to get involved/contribute to Mozilla
> | | http://mozilla.org/get-involved.html
> | |
> | |--advocacy/ - Mozilla advocacy guides
> | |
> | |--evang/ - Evangelism guides

Avoid unnecessary abbreviations in URIs, this should be evangelism/.

That should be mozilla/ instead of hacking/, since it is specific to one
of mozilla.org's many projects. Bugzilla, for instance, has different
checkin guidlines, different coding standards, different reviewers guides.

write-access/ should probably be called cvs/ and be one level higher
(i.e., under contribute/ instead of contribute/mozilla/).

Should qa/ be under contribute/mozilla/ ? That depends on how much detail
we put in there.

> | |
> | |--tools/ - tools for contributing
> | | | http://mozilla.org/tools.html
> | | |
> | | |--bugzilla/ - for use of Bugzilla
> | | | http://mozilla.org/bugs/
> | | |
> | | |--bonsai/ - for use of Bonsai
> | | | http://mozilla.org/bonsai.html (top half)
> | | |
> | | |--cvs/ - for use of CVS
> | | | http://mozilla.org/cvs.html
> | | |
> | | |--tinderbox/ - for use of Tinderbox
> | | | http://mozilla.org/tinderbox.html
> | | |
> | | |--zope/ - for using Zope
> | |
> | |--writing/ - document writing/coding/uploading/style guidelines
> |
> |--dev/ - all development-related information
> | |
> | |--tech/ - Mozilla technologies
> | | |
> | | |--xul/
> | | |
> | | |--js/
> | | |
> | | |--xpcom/
> | |
> | |--ports/ - Platform homepages
> | | |
> | | |--beos/
> | | |
> | | |--macosx/
> | |
> | |--_?_/ - Mozilla developers' stuff

?

> | |
> | |--web/ - Web Developer info - articles on writing pages for
> | | Mozilla, FAQ, show-off section, etc.
> | |
> | |--embed/ - info for potential embedders of Mozilla tech.
> |
> |--events/
> | |
> | |--year/ - all events for year
> | |
> | |--event_name/ - all files associated with event
> |
> |--license/ - MPL, NPL, current licensing strategy
> |
> |--software/ - list of software released by mozilla.org w/ description
> | |
> | |--mozilla/ - intro & description for all of Mozilla
> | | |
> | | |--build/ - build instructions
> | | | | http://mozilla.org/build/
> | | | |--beos/
> | | | |
> | | | |--mac/
> | | | |
> | | | |--macosx/
> | | | |
> | | | |--os2/
> | | | |
> | | | |--unix/
> | | | |
> | | | |--win32/

Is this redundant with contrinute/mozilla/ ? Or are they subtly
different? (The hacking guidelines for each project should probably point
to any relevant documents in the project documentation, which is basically
what this is, right?)

Also, mozbot/ - basically what's in projects/mozbot/ now.

> | |--etc.,
> |
> |
> |--news/ - news items (may be links to other parts of the site)
> | |
> | |--year/ - all news items for year
> | | |
> | | |--month/ - all news items for month (numerical - e.g. 05)
> | | |
> | | |--article/ - all files associated with the article,
> | | directory named after article title
> | |
> | |--status/
> |
> |--support/ - links to product-specific info under /software/product

Redundant?

> Key URLs from the old site, such as /MPL and /releases, will
> be handled by redirects.

Why only key redirects? Think about search engines, bookmarks, URIs in
random documents on the web, etc. I think it would not be that hard to
redirect the overwhelming majority of links. On my own sites I regularly
look through my logs and add redirects for almost any old 404, including
typos; existing files which have moved should IMHO _always_ be redirected.

HTH,
--
Ian Hickson )\ _. - ._.) fL
/. `- ' ( `--'
`- , ) - > ) \
irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________

Gervase Markham

unread,

Sep 3, 2001, 9:25:02 PM9/3/01

to

Most of this sounds good to me.

>> |--software/ - list of software released by mozilla.org w/ description
>> | |
>> | |--mozilla/ - intro & description for all of Mozilla
>> | | |
>> | | |--build/ - build instructions
>> | | | | http://mozilla.org/build/
>> | | | |--beos/
>> | | | |
>> | | | |--mac/
>> | | | |
>> | | | |--macosx/
>> | | | |
>> | | | |--os2/
>> | | | |
>> | | | |--unix/
>> | | | |
>> | | | |--win32/
>>
>
> Is this redundant with contrinute/mozilla/ ? Or are they subtly
> different? (The hacking guidelines for each project should probably point
> to any relevant documents in the project documentation, which is basically
> what this is, right?)

This split is fantasai's work; I'll let her explain.

>> | |--bugzilla/ - for using Bugzilla on your own system
>> | | (subdirectory structure similar to mozilla/,
>> | | above)
>
> Also, mozbot/ - basically what's in projects/mozbot/ now.

The directories shown are representative. ;-)

>> |--support/ - links to product-specific info under /software/product
>
> Redundant?

Again, the work of others. I personally think we don't need it.

>> Key URLs from the old site, such as /MPL and /releases, will
>> be handled by redirects.
>
> Why only key redirects? Think about search engines, bookmarks, URIs in
> random documents on the web, etc. I think it would not be that hard to
> redirect the overwhelming majority of links. On my own sites I regularly
> look through my logs and add redirects for almost any old 404, including
> typos; existing files which have moved should IMHO _always_ be redirected.

Well, we do plan to check 404 logs in case we miss important ones, and
use http://www.mozilla.org/weblogs/ as well. The problem with
redirecting everything is that a) it's a pain to set up, and b) it
doesn't encourage people to start using the new URLs.

The often-quoted document on this topic is:
http://www.w3.org/Provider/Style/URI.html

It says:
[ Why do URIs dangle? ]

"We just reorganized our website to make it better.

Do you really feel that the old URIs cannot be kept running? If so, you
chose them very badly. Think of your new ones so that you will be able
to keep then running after the next redesign."

This is us, and we are doing exactly what he says :-)

Gerv

fantasai

unread,

Sep 4, 2001, 12:08:48 AM9/4/01

to

> |--news/ - news items (may be links to other parts of the site)
> | |
> | |--year/ - all news items for year
> | | |
> | | |--month/ - all news items for month (numerical - e.g. 05)
> | | |
> | | |--article/ - all files associated with the article,
> | | directory named after article title
> | |
> | |--status/

IIRC, we agreed on moving events/ under news/:

|--news/ - news items (may be links to other parts of the site)
| |
| |--year/ - all news items for year
| |

| |--month/ - all news items and announcements for month

| |--events/ - All events for this year
| |
| |--status/ - All status reports for this year
| |
| |--month/ - All status reports for month (numerical)
| |
| |--num/ - Status report, num = release date

fantasai

unread,

Sep 4, 2001, 1:52:25 AM9/4/01

to

Ian Hickson wrote:
>
> > | |--evang/ - Evangelism guides
>
> Avoid unnecessary abbreviations in URIs, this should be evangelism/.

ok. Should /dev also be expanded?

> > /about/community

>
> I think community/ should be its own top level directory,
> emphasising its importance. Encouraging community involvement
> is one of the main things missing on www.mozilla.org right
> now. The community/ section should explain how to join mailing
> lists and IRC, and should cater for whatever projects are
> being worked on (e.g. Bugzilla, Mozilla, Mozbot) whereas
> about/ should, by its nature, be pretty static information
> about the mozilla.org organisation itself.

The community page describes the mozilla community and
where to find it. The page /is/ not the community nor
it's meeting place--it only describes it. So, it is
fairly static.

My argument goes like this:
Assuming the community is part of the mozilla organization,
by describing the community it describes the mozilla
organization. It is -about- the mozilla organization and
thus belongs under /about.

Pages catering to individual projects will go in their
respective development directories, and links to specific
groups can appear anywhere.

> > | |--hacking/ - general rules and guidelines for hacking
> > | | | Mozilla code
> > | | | http://mozilla.org/hacking/nutshell.html
>
> That should be mozilla/ instead of hacking/, since
> it is specific to one of mozilla.org's many projects.
> Bugzilla, for instance, has different checkin
> guidlines, different coding standards, different
> reviewers guides.

Contributing to mozilla doesn't necessarily mean hacking,
so perhaps it should be /hacking/mozilla?

> > | | |--write-access/ - getting CVS access
> > | | | | http://mozilla.org/hacking/
> > | | | | getting-cvs-write-access.html
> > | | | |
> > | | | |--cvs-form/ - CVS access form
>
> write-access/ should probably be called cvs/ and
> be one level higher (i.e., under contribute/
> instead of contribute/mozilla/).

It's called write-access because the text applies whether
or not we're using CVS. It's not under contribute/ because
it does not apply to QA, writing, or anything besides
hacking. Even if it did, the requirements for write access
would be different for each one.

> Should qa/ be under contribute/mozilla/ ? That depends
> on how much detail we put in there.

I think it's fine under /contribute. If some docs go into
too much detail, they can split off under qa/. Most of the
stuff in Quality Assurance is not mozilla-specific, but
does apply to Mozilla--so Mozilla-specific qa documentation
should go under /contribute/qa to pick that info up.

The hierarchy should look like this:

Least specific
|
|--more specific, but least-specific stuff still applies

> > |--dev/ - all development-related information
> > | |

> > | |--_?_/ - Mozilla developers' stuff
>
> ?

Mozilla development project directories go under /dev
somewhere. (That would be most of the stuff linked from
http://mozilla.org/projects right now.) Exactly where and
under what categorization remains to be determined.
(Bugzilla development docs also go here, etc.)

> > |--software/ - list of software released by mozilla.org
> > w/ description
>

> Is this redundant with contrinute/mozilla/ ? Or are
> they subtly different? (The hacking guidelines for
> each project should probably point to any relevant
> documents in the project documentation, which is
> basically what this is, right?)

Project documentation--developers' documentation--go under
the appropriate directory in /dev.

/software is for all the software released by mozilla.org
It provides one place for the visitor to see everything we
offer.

This is where you get download and installation instructions
(including build instructions). This is where we put all the
advertising hype--developers know the software's features well
enough and don't need filter through that. This is where we
archive releases and their relnotes--developers are working on
the bleeding edge and don't need that info.

Everything in /software is targeted at people who come here to
get the software. They don't have to filter through developers'
news, technical notes, freeze dates, or any information on how
it works or what the lead team is prioritizing right now.

Mozilla distributions are linked from /software/mozilla; so
are skins. Langpack releases also appear here, and any other
paraphernalia that goes with the software. Everything's in one
place, and because developers' docs are in /dev, content can
be written around the "customer"--and potential contributor--
"don't forget to report any bugs", "Help us port Mozilla to
BeOS!" etc.

Here's a response to Gervase I wrote back in December:

| > But why do you think the distinction between software-in-development and
| > software-that's-released is so big as to split the two parts apart? Why
| > can't they live together?
|
| - They are aimed at different audiences.
| - Their purposes are completely different.
| - They don't follow the same time-table.
| - Releases don't always correspond with major changes in code that
| require documentation changes or additions; they come out after
| many minor changes, also.
| - Major changes to the code don't immediately trigger new releases;
| the code must be tested and stabilized first.
| - Software-that's-released is static. Software-in-development is dynamic.
|
| As I see it, if you were to create a table of all the project-related docs,
| you would get something like this:
|
| || Development Docs || Use Docs (not "User") |
| ||overview|documentation|project-org||overview|relnotes|build-instruc|
| -------||----------------------------------||-------------------------------|
| project||what is |how does it |community/ ||what's |(self- |how to get it|
| name || it? | work? |involvment || it do? |explain)| |
|
| You want the split along each row, then by columns
| I want it along the column groups, then by rows, then by columns.

-- http://groups.google.com/groups?selm=3A4289DD.9928B082%40escape.com

fantasai

unread,

Sep 4, 2001, 11:40:38 AM9/4/01

to

I was thinking about this earlier this morning, so I'm
answering myself..

fantasai wrote:
>
> Ian Hickson wrote:
> >
> > > | |--evang/ - Evangelism guides
> >
> > Avoid unnecessary abbreviations in URIs, this should be evangelism/.
>
> ok. Should /dev also be expanded?

No, it should not. It's easier to type, and "dev" is a very
common, well known abbreviation. Were it to expand, it could
be /develop, /developer, or /development--it's easier to
remember /dev. And on top of that, the abbreviation is also
valid in French. :)

Heikki Toivonen

unread,

Sep 4, 2001, 6:15:07 PM9/4/01

to

I somehow find the software hierarchy odd... And I would expect build
instructions on the dev hierarchy. Should there be download hierarchy
for readily available binaries and other products?

I would also like to have redirects for all old URIs, regardless of what
some guideline says. Eventually people will update if you make the
redirect a bit slow, like 3-5 seconds instead of immediate ;)

Gervase Markham wrote:

> mozilla.org/

> |
> |--dev/ - all development-related information
> | |
> | |--tech/ - Mozilla technologies
> | | |
> | | |--xul/
> | | |
> | | |--js/
> | | |
> | | |--xpcom/
> | |
> | |--ports/ - Platform homepages
> | | |
> | | |--beos/
> | | |
> | | |--macosx/
> | |
> | |--_?_/ - Mozilla developers' stuff
> | |
> | |--web/ - Web Developer info - articles on writing pages for
> | | Mozilla, FAQ, show-off section, etc.
> | |
> | |--embed/ - info for potential embedders of Mozilla tech.
> |

> |--software/ - list of software released by mozilla.org w/ description
> | |
> | |--mozilla/ - intro & description for all of Mozilla
> | | |
> | | |--build/ - build instructions
> | | | | http://mozilla.org/build/
> | | | |--beos/
> | | | |
> | | | |--mac/
> | | | |
> | | | |--macosx/
> | | | |
> | | | |--os2/
> | | | |
> | | | |--unix/
> | | | |
> | | | |--win32/
> | | |
> | | |--distributors/ - link to Mozilla distributors
> | | | (e.g. Netscape, Beonex)
> | | |
> | | |--releases/ - Mozilla release info (one directory per
> | | | release)
> | | | http://mozilla.org/releases/
> | | |
> | | |--0.6/ - relnotes and stuff
> | |
> | |--bugzilla/ - for using Bugzilla on your own system
> | | (subdirectory structure similar to mozilla/,
> | | above)
> | |--etc.,

--
Heikki Toivonen

fantasai

unread,

Sep 4, 2001, 8:26:38 PM9/4/01

to

Heikki Toivonen wrote:
>
> I somehow find the software hierarchy odd... And I
> would expect build instructions on the dev hierarchy.

Build instructions are more closely associated with
download/installation than with the developing the
software's internals IMO. Remember, mozilla.org
produces source. Thus building is a regular part of
acquiring the software.

/dev isn't targeted at someone who's just going to
download and use the source as is, and non-developers
shouldn't need to wander around in there to look for
build instructions.

One could argue that building is a regular part of
development, too, but that doesn't apply to modifying
the chrome. In any case, developers, like anyone else
getting Mozilla by source, still have to download,
build, and install the software. So, like everyone
else, they can get all the instructions for doing that
from the same place.

> Should there be download hierarchy for readily
> available binaries and other products?

This is what /software is for--acquiring software.
Source and/or binaries.

Gervase Markham

unread,

Sep 4, 2001, 10:51:01 PM9/4/01

to

Heikki Toivonen wrote:

> I somehow find the software hierarchy odd... And I would expect build
> instructions on the dev hierarchy.

Hmm. Yes.

> Should there be download hierarchy
> for readily available binaries and other products?

That is the software hierarchy.

> I would also like to have redirects for all old URIs, regardless of what
> some guideline says. Eventually people will update if you make the
> redirect a bit slow, like 3-5 seconds instead of immediate ;)

The thing is that doing all URIs is a pretty big problem.

We'll do as many as we can find volunteers to do :-)

Gerv

Ian Hickson

unread,

Sep 5, 2001, 8:18:15 AM9/5/01

to Gervase Markham, mozilla-do...@mozilla.org

On Tue, 4 Sep 2001, Gervase Markham wrote:
>
> The thing is that doing all URIs is a pretty big problem.

Why?

I volunteer to work on this if required.

l337hx0r

unread,

Sep 5, 2001, 8:56:20 AM9/5/01

to

>I volunteer to work on this if required.

Ditto.

Gervase Markham

unread,

Sep 5, 2001, 1:00:13 PM9/5/01

to Ian Hickson, mozilla-do...@mozilla.org

Ian Hickson wrote:

> On Tue, 4 Sep 2001, Gervase Markham wrote:
>
>>The thing is that doing all URIs is a pretty big problem.
>>
>
> Why?

Because there are a lot of them, and the mappings will often be a case
of nearest-equivalent, so their setting up can't be automated.

> I volunteer to work on this if required.

Thanks :-)

Gerv

Henri Sivonen

unread,

Sep 5, 2001, 1:14:39 PM9/5/01

to

In article <3B95713E...@escape.com>, fantasai
<fant...@escape.com> wrote:

> This is what /software is for--acquiring software.
> Source and/or binaries.

Shouldn't the keyword be "download" then?

I think most people who are looking for software downloads scan the
front page for a link that says "Download" and then click that link.

--
Henri Sivonen
hen...@clinet.fi
http://www.clinet.fi/~henris/

Gervase Markham

unread,

Sep 5, 2001, 2:16:58 PM9/5/01

to

> I think most people who are looking for software downloads scan the
> front page for a link that says "Download" and then click that link.

It will say that on the front page. Please don't make the mistake of
assuming that the URI structure and the navigational structure are the
same, either in shape or in terms of the words used.

That directory contains more than just downloads. Software is one
possibility for an appropriate name, although there are others.

Gerv

fantasai

unread,

Sep 6, 2001, 9:49:17 PM9/6/01

to

Gervase Markham wrote:
>
> |--dev/ - all development-related information
> | |
> | |--tech/ - Mozilla technologies
> | | |
> | | |--xul/
> | | |
> | | |--js/
> | | |
> | | |--xpcom/

What sort of documents fall under /dev/tech? Could you give a
sort of general description? "Mozilla technologies" is very
vague.

Gervase Markham

unread,

Sep 7, 2001, 12:34:02 PM9/7/01

to

fantasai wrote:

/dev/tech/xul is the current /projects/xul (not much there right now)
/dev/tech/js is the current /js
/dev/tech/xpcom is the current /projects/xpcom .
etc.

Gerv

fantasai

unread,

Sep 7, 2001, 4:40:45 PM9/7/01

to

Gervase Markham wrote:

>
> fantasai wrote:
>
> >
> > What sort of documents fall under /dev/tech? Could you give a
> > sort of general description? "Mozilla technologies" is very
> > vague.
>
> /dev/tech/xul is the current /projects/xul (not much there right now)
> /dev/tech/js is the current /js

Does /dev/tech/js include http://mozilla.org/js/spidermonkey/?

> /dev/tech/xpcom is the current /projects/xpcom .
> etc.

Can you give me a more solid basis for extrapolating that?
A rule, maybe? Those three are as good as getting 1, 2, 4
for a number sequence.

Gervase Markham

unread,

Sep 7, 2001, 7:32:47 PM9/7/01

to

> Can you give me a more solid basis for extrapolating that?
> A rule, maybe? Those three are as good as getting 1, 2, 4
> for a number sequence.

Here are some more:

crypto
directory
dom
js-engine
layout
mathml
netlib
nspr
oji
plugins
rdf
style
svg
xbl
xml
xpcom
xpfe
xpinstall
xslt
xul

I'm sure you can find the relevant current web pages, if they exist
(which they do for most of the technologies on this list.)

Gerv

fantasai

unread,

Sep 7, 2001, 11:47:50 PM9/7/01

to

Gervase Markham wrote:
>
> > Can you give me a more solid basis for extrapolating that?
> > A rule, maybe? Those three are as good as getting 1, 2, 4
> > for a number sequence.
>
> Here are some more:
>

>...

>
> I'm sure you can find the relevant current web pages, if they exist
> (which they do for most of the technologies on this list.)

Ah, so you've basically taken the all Mozilla's software development
projects from http://mozilla.org/projects/ and put them in /dev/tech.

So, extending the list, I add

browser
editor
irc
p3p
vixen
xpconnect
xpnet

but not

bugzilla
i18n
performance
bonsai

Am I on the right track?

Fabian Guisset

unread,

Sep 8, 2001, 4:05:17 AM9/8/01

to

fantasai wrote:
> Gervase Markham wrote:
>
>>>Can you give me a more solid basis for extrapolating that?
>>>A rule, maybe? Those three are as good as getting 1, 2, 4
>>>for a number sequence.
>>>
>>Here are some more:
>>
>>...
>>
>>I'm sure you can find the relevant current web pages, if they exist
>>(which they do for most of the technologies on this list.)
>>
>
> Ah, so you've basically taken the all Mozilla's software development
> projects from http://mozilla.org/projects/ and put them in /dev/tech.
>
> So, extending the list, I add
>
> browser

no
> editor
no
> irc
no
> p3p
yes
> vixen
no
> xpconnect
yes
> xpnet
what is that

All those I labeled with a no are "products" which we may want to
separate from Mozilla in the future. /dev/tech, as I see it, and as we
discussed it before, are the raw technologies developed in Mozilla. The
browser is not a technology, it makes uses of a set of technology, same
goes for editor and chatzilla and vixen. The P3P however is a technology
in itself, same goes for xpconnect, and all those that Gerv mentioned.

The ones you mention below should indeed not appear in /dev/tech
Bugzilla and Bonsai should be with LXR with the other webtools.

-Fabian.

fantasai

unread,

Sep 8, 2001, 11:09:10 AM9/8/01

to

Fabian Guisset wrote:
>
> fantasai wrote:
> >
> > xpnet
> what is that

http://mozilla.org/projects/xpnet/

> All those I labeled with a no are "products" which we may want to
> separate from Mozilla in the future.

Why aren't XSLT and XPCOM considered "products"?
http://mozilla.org/projects/xslt/
http://mozilla.org/projects/xpcom/

> /dev/tech, as I see it, and as we discussed it before, are the raw
> technologies developed in Mozilla. The browser is not a technology,
> it makes uses of a set of technology, same goes for editor and
> chatzilla and vixen.

By definition, all software is technology. What makes editor so
different from, say, layout that you don't consider it a "technology"?
What is your definition of "technology"?

> Bugzilla and Bonsai should be with LXR with the other webtools.

LXR is not developed by Mozilla.[1] That point aside, are you
proposing a /dev/webtools directory?

[1] http://lxr.mozilla.org/

Matthew Thomas

unread,

Sep 9, 2001, 2:18:34 PM9/9/01

to mozilla-do...@mozilla.org

fantasai wrote:
>...

> fantasai wrote:
> >
> > Ian Hickson wrote:

>...

> > > Avoid unnecessary abbreviations in URIs, this should be
> > > evangelism/.
> >
> > ok. Should /dev also be expanded?
>
> No, it should not. It's easier to type, and "dev" is a very
> common, well known abbreviation. Were it to expand, it could
> be /develop, /developer, or /development--it's easier to
> remember /dev. And on top of that, the abbreviation is also
> valid in French. :)

By the same logic, /contribute/ should be /contrib/. It's easier to
type, and `contrib' is a very common, well-known abbreviation (used by
geeky FTP servers worldwide). Were it to expand, it could be
/contribute/, /contributor/, or /contribution/ ...

Also by the same logic, <http://mozilla.org/> should be changed to
<http://moz.org/>. It's easier to type, and `Moz' is a very common,
well-known abbreviation ...

--
M. `mpt' T., M. UI D. c. d. a. t.
<http://m.o/>

Matthew Thomas

unread,

Sep 9, 2001, 2:29:57 PM9/9/01

to mozilla-do...@mozilla.org

Fabian Guisset wrote:
>
> fantasai wrote:

>...

> > Ah, so you've basically taken the all Mozilla's software development
> > projects from http://mozilla.org/projects/ and put them in
> > /dev/tech.
> >
> > So, extending the list, I add
> >
> > browser
> no
> > editor
> no
> > irc
> no
> > p3p
> yes
> > vixen
> no
> > xpconnect
> yes

>...

> All those I labeled with a no are "products" which we may want to
> separate from Mozilla in the future.

I think that if the Mozilla Organization decided to separate the
browser/ from Mozilla in the future, they would have lost the plot so
severely that it wouldn't matter what their site's URI structure was.
:-)

> /dev/tech, as I see it, and as we
> discussed it before, are the raw technologies developed in Mozilla.
> The browser is not a technology, it makes uses of a set of technology,
> same goes for editor and chatzilla and vixen. The P3P however is a
> technology in itself,

>...

P3P could conceivably get a standalone UI in the future (after all, Web
browsers aren't the only apps which accept cookies, so a `P3P Manager'
could protect your entire OS profile), whereupon it would suddenly
change from being a `technology' to being a `product' with a misleading URI.

Is PSM a `product', or a `technology'?

You may be able to make the distinction between `products' and
`technologies' today, and such a distinction would possibly be useful to
convey in various sections on the /develop/mozilla/ index page. But
trying to hardwire that distinction into the URI is something I think
would end in tears later on when modules jumped from one category to the other.

--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>

Matthew Thomas

unread,

Sep 9, 2001, 2:12:43 PM9/9/01

to mozilla-do...@mozilla.org

Ian Hickson wrote:
>...

> > mozilla.org/
> > |
> > |--about/ - about mozilla.org
> > | | http://mozilla.org/mozorg.html
> > | |
> > | |--community/ - newsgroups, IRC, mailing lists
> > | | http://mozilla.org/community.html
>
> I think community/ should be its own top level directory, emphasising
> its importance. Encouraging community involvement is one of the main
> things missing on www.mozilla.org right now.

That's what /contribute/ is for.

> The community/ section
> should explain how to join mailing lists and IRC,

/contribute/discuss/

IMO each group should have its own page, with a description of the
group, links for subscribing/unsubscribing from the newsgroup and from
the mailing list, and links to archives at Google Groups and Geocrawler.
Then those pages can be linked to from /contribute/discuss/, and from
the relevant sections (e.g. /develop/web/ can link to
/contribute/discuss/mozilla.web-developer/).

>...

> Also colophon/, explaining how the site itself was created.

/about/site/ would perhaps be more obvious than /about/colophon/. (There
could be some interesting links between /about/site/ and
/develop/web/, if the mozilla.org site itself is used to show off things
such as alternate style sheets.)

>...

> > | |--evang/ - Evangelism guides
>
> Avoid unnecessary abbreviations in URIs, this should be evangelism/.

Same goes for /develop/.

> > | |--hacking/ - general rules and guidelines for hacking
> > | | | Mozilla code
> > | | | http://mozilla.org/hacking/nutshell.html
>
> That should be mozilla/ instead of hacking/, since it is specific to
> one of mozilla.org's many projects. Bugzilla, for instance, has
> different checkin guidlines, different coding standards, different
> reviewers guides.

Then /contribute/hacking/ can link to the specific instructions for
those products which have different rules, products which make up a
small minority of the total hacking that is overseen by the Mozilla Organization.

>...

> > | | |--write-access/ - getting CVS access

>...

> > | | | |--cvs-form/ - CVS access form
>
> write-access/ should probably be called cvs/ and be one level higher
> (i.e., under contribute/ instead of contribute/mozilla/).

I agree about the renaming, but (and I hesitate to ask a rhetorical
question, for fear of getting an answer) why would you want to use CVS
if not to hack on the code? (Remember that the Web site will no longer
be using CVS.:-)

/contribute/hacking/cvs/
/contribute/hacking/cvs/diffs/
/contribute/hacking/cvs/write/
/contribute/hacking/cvs/write/application/
/contribute/hacking/cvs/mac/
/contribute/hacking/cvs/win32/

>...

> Should qa/ be under contribute/mozilla/ ? That depends on how much
> detail we put in there.

I think most information about filing bugs, finding duplicates, etc is
relevant no matter whether it's Mozilla, Bugzilla, or whatever else
you're doing QA for.

>...

> > |--dev/ - all development-related information

>...

> > |--software/ - list of software released by mozilla.org w/

>...

> > | |--mozilla/ - intro & description for all of Mozilla
> > | | |
> > | | |--build/ - build instructions
> > | | | | http://mozilla.org/build/
> > | | | |--beos/
> > | | | |
> > | | | |--mac/

>...

> Is this redundant with contrinute/mozilla/ ? Or are they subtly
> different? (The hacking guidelines for each project should probably
> point to any relevant documents in the project documentation, which is
> basically what this is, right?)

The build instructions for compiling Mozilla 0.8
(/software/mozilla/0.8/build/) will never change. The build instructions
for compiling from current CVS (/contribute/hacking/mozilla/build/ or
whatever) may not change very often, but they will change more often
than never. As each release is branched, a snapshot of the build
instructions as they are at that time should be placed in the /software/
directory for that version.

>...

> > |--support/ - links to product-specific info under
> > /software/product
>
> Redundant?

This is for directing those who come to mozilla.org looking for a
spell-checker for Mozilla, or wanting to know how to install Mozilla and
Netscape 6.1 in peaceful coexistence, or trying to get help with a
Bugzilla configuration problem, or whatever, to the appropriate
newsgroups (i.e. not developer groups), IRC channels, and distributors.

> > Key URLs from the old site, such as /MPL and /releases, will
> > be handled by redirects.
>
> Why only key redirects? Think about search engines, bookmarks, URIs in
> random documents on the web, etc. I think it would not be that hard to
> redirect the overwhelming majority of links.

>...

I agree. Even where there isn't a direct or even a close equivalent in
the new site to a particular page on the old site, we should really be
returning a 410 error instead of a 404. :-)

Fabian Guisset

unread,

Sep 9, 2001, 4:38:17 PM9/9/01

to

Matthew Thomas wrote:

>
> You may be able to make the distinction between `products' and
> `technologies' today, and such a distinction would possibly be useful to
> convey in various sections on the /develop/mozilla/ index page. But
> trying to hardwire that distinction into the URI is something I think
> would end in tears later on when modules jumped from one category to the other.
>
>

What do you propose then? A generic /project? A generic /module? A
generic /product? A generic /tech? A generic something else?
-Fabian.

fantasai

unread,

Sep 9, 2001, 4:57:45 PM9/9/01

to

List the advantages of expanding /dev to /develop.

fantasai

unread,

Sep 9, 2001, 7:12:57 PM9/9/01

to

Matthew Thomas wrote:

>
> Ian Hickson wrote:
> >...
> > > | | |--write-access/ - getting CVS access
> >...
> > > | | | |--cvs-form/ - CVS access form
> >
> > write-access/ should probably be called cvs/ and be one level higher
> > (i.e., under contribute/ instead of contribute/mozilla/).
>
> I agree about the renaming, but (and I hesitate to ask a rhetorical
> question, for fear of getting an answer) why would you want to use CVS
> if not to hack on the code? (Remember that the Web site will no longer
> be using CVS.:-)
>
> /contribute/hacking/cvs/

Directions specifically for using cvs should go under
/contribute/tools/cvs, along with the info for all the
other tools.

Both the site and the code currently use CVS, Bugzilla, and
Bonsai. The site is changing to Zope, but that won't preclude
the use of Bugzilla for various mozilla.org issues.

Tools can cross the boundaries laid down under /contribute--
this is why they're factored out into /contribute/tools.
CVS should not be a special exception.

> /contribute/hacking/cvs/write/
> /contribute/hacking/cvs/write/application/

Luke

unread,

Sep 10, 2001, 9:38:56 AM9/10/01

to

1) I have a strong opinion on these bits:

/contribute/community/ not /about/community/
/contribute/documentation/ not /contribute/writing/
/news/events/ not /events/
/develop/ not /dev/
/develop/build/ not /software/mozilla/build/
(How many non-developers really build Mozilla? I sure don't.)

2) My main problem: I don't like the /software/ hierarchy. It's trying
to do 2 things at once.

The 2 meanings of the word "software" are being blurred.

1 - /software/mozilla/ = here's the software (i.e. the actual files)
to download & build
2 - /software/bugzilla/ = everything about bugzilla, the project
i.e. a category for dividing the site

I'd do one hierarchy for downloading Mozilla

/download/
/releases/
/nightlies/
/distributions/

and another for other software projects: the non-browser projects
currently listed waay down the bottom of the /projects/ page (or not).

/software/ or /projects/ or even /othersoftware/
/bonsai/
/bugzilla/
/tinderbox/
/grendel/
/vixen/
/rhino/

3) I love how /dev/tech/ stuff has finally been grouped together sensibly.

4) Should /develop/web/ be a separate hierarchy maybe? Isn't /develop/
for developing Mozilla itself - not developing sites for Mozilla?
/web/? /webdev/? OK so I'm crazy. Ignore this one if you like.

5) Where do theme developers go? is /develop/tech/xul/themes/ too deep?

6) I'm into redirects where possible.

At the end of the day...

- All this talk about URIs being static for eternity is bollocks. Great
idea, but don't sweat it too much, or we'll keep moving too slow.
(newsgroup hierarchy?)

- It's the navigation hierarchy & content that really matters. Making
the information easy to find, even if you start at the top. I'd be less
concerned about what happens if someone has done deep bookmarks all over
the place.

- And then, of course, there's the content. Less is more. Waiting for
Zopot...

My 3c...

Luke
--
lu...@strangemonkey.com

Gervase Markham

unread,

Sep 10, 2001, 1:26:23 PM9/10/01

to

> IIRC, we agreed on moving events/ under news/:

Well, they aren't always news. The mozilla2.0 party is not (currently)
news. And yes, you could say this about all stuff that's happened, but
events can also be planned months in advance, and the planning process
is not news.

Gerv

Gervase Markham

unread,

Sep 10, 2001, 1:39:14 PM9/10/01

to

Luke wrote:

> 1) I have a strong opinion on these bits:
>
> /contribute/community/ not /about/community/

But you don't contribute to the community. At least, not in the sense
that you contribute to Mozilla. If all we're doing is rephrasing the
current /community.html (which seems likely) then /about/community is
fine. The community is not on the website, in one sense - and in the
sense that it is on the website, it's on the whole thing.

> /contribute/documentation/ not /contribute/writing/

All documentation is writing, but not all writing is documentation. If
you were contributing an op-ed piece, you'd still need to reference the
style guidelines in here.

> /news/events/ not /events/

See my previous post.

> /develop/ not /dev/

Loads of other projects use /dev/. It's understood, and it's easier to
type. It also matches the newsgroup spec.

> 2) My main problem: I don't like the /software/ hierarchy. It's trying
> to do 2 things at once.
>
> The 2 meanings of the word "software" are being blurred.
>
> 1 - /software/mozilla/ = here's the software (i.e. the actual files)
> to download & build
> 2 - /software/bugzilla/ = everything about bugzilla, the project

You are right.

My idea was:

For meaning 2:
/projects
/projects/bugzilla/
/projects/browser/
/projects/mailnews/
/projects/irc/

And, for downloading stuff (meaning 1), /releases/.

/releases/mozilla/0.9.3/
/releases/mozilla/nightlies/
/releases/bugzilla/2.14/
etc.
Build instructions live under /dev, but are linked from the /releases/ area.

Almost exactly like you said, in fact :-)

> 5) Where do theme developers go? is /develop/tech/xul/themes/ too deep?

Probably in their personal space under /Members. And no, you weren't
supposed to know about that unless you know Zope. ;-)

Gerv

Fabian Guisset

unread,

Sep 10, 2001, 1:58:58 PM9/10/01

to

Gervase Markham wrote:

>> 5) Where do theme developers go? is /develop/tech/xul/themes/ too deep?
>
>
> Probably in their personal space under /Members. And no, you weren't
> supposed to know about that unless you know Zope. ;-)
>
>
> Gerv
>

Actually I think he meant the mozilla skin designers, not the website
skin designers.
Since themes are more than just xul, it would probably be good to have
/dev/themes or /contribute/themes or perhaps /tech/xpfe/themes, if we're
keeping something like xpfe around.

-Fabian.

Gervase Markham

unread,

Sep 10, 2001, 3:11:24 PM9/10/01

to

Fabian Guisset wrote:

> Gervase Markham wrote:
>
>>> 5) Where do theme developers go? is /develop/tech/xul/themes/ too deep?
>>
>>
>>
>> Probably in their personal space under /Members. And no, you weren't
>> supposed to know about that unless you know Zope. ;-)
>>
>>
>> Gerv
>>
>
> Actually I think he meant the mozilla skin designers, not the website
> skin designers.

So did I :-) We should encourage theme authors to host their themes on
mozilla.org if they like - but probably in their personal directories.

If you mean classic and modern, they currently don't have any web pages.
If they wanted them, I would say probably /dev/themes. If we have
/dev/web, we can have /dev/themes. Developing themes cuts across
/dev/tech/xul , /dev/tech/js etc.

I think we should try and kill "xpfe". More people understand "ui".

Gerv

Luke

unread,

Sep 10, 2001, 9:39:21 PM9/10/01

to

Fabian's definitions of /projects/ vs /dev/tech/ sum it up really well.
A product is something that can be used on its own. That's the rule
of thumb. So what do we have...
/dev/tech/ xul, etc
/projects/ bugzilla, bonsai, etc
/releases/ files to download (I'd still prefer the obvious
/download/ now that this hierarchy isn't broad/mixed
as /software/, but anyhow...)

I also like
/dev/ui/ instead of xpfe
/dev/themes/

/dev/themes/ is what I was after, thanks Gerv - as you said it cuts
across lots of /tech/. But it would be a place for finding/adding
information on creating themes, not individual themes, not just classic
& modern. (Individual themes under /members/ works for me, btw.)

I still don't like /community/ where it is under /about/. I think the
word "community" means 2 things at once again (like /software/). It
means newsgroups, mostly, but it also refers to the mozilla community as
people. How about a broader /community/ hierarchy at the root,
something like this?

/community/
/events/
/2002/
/newsgroups/ (or /forums/ ?)
/newsbot/
/irc/
/links/

Luke
--
lu...@strangemonkey.com

fantasai

unread,

Sep 10, 2001, 11:03:49 PM9/10/01

to

Luke wrote:
>
> /develop/build/ not /software/mozilla/build/
> (How many non-developers really build Mozilla? I sure
> don't.)

/software/mozilla should contain all the info needed to
get Mozilla up and running. As the main product here is
source code, this includes build instructions.

You said you're into UE -- analyze this organization from
the visitor's standpoint. Remember that although the
navigation is not restricted by the URI hierarchy, the
navigational hierarchy does coincide with it. You're trying
to download/install Mozilla--should the build instructions
transport you to the developers' hierarchy?

> 2) My main problem: I don't like the /software/ hierarchy.
> It's trying to do 2 things at once.

Which 2 things? A directory grouping both software download
and software development is doing two things at once, and
that's been purposely avoided here.

/dev takes care of development
/software takes care of download/install
i.e.

> 1 - /software/mozilla/ = here's the software (i.e. the
> actual files) to download &
> build

If you don't like the name "software", that's another issue.
Would "products" suit better?

> I'd do one hierarchy for downloading Mozilla and another
> for other software projects:

Your justification for this separation?

If it's "only Mozilla should get the spotlight," then I'd
tell you to write your content to that bias, not your URIs.

> - All this talk about URIs being static for eternity is
> bollocks. Great idea, but don't sweat it too much, or
> we'll keep moving too slow.

Eternity, no. But if the URI is planned extensibly, with
likely future changes in mind, it makes things easier in
the long run.

[OT]
> (newsgroup hierachy?)

The newsgroup hierarchy is held up by server issues,
not by the design effort, which, IIRC, finalized a spec
with general consensus _last year_.

Matthew Thomas

unread,

Sep 10, 2001, 12:58:36 PM9/10/01

to mozilla-do...@mozilla.org

Fabian Guisset wrote:
>
> Matthew Thomas wrote:
>...

> > You may be able to make the distinction between `products' and
> > `technologies' today, and such a distinction would possibly be
> > useful to convey in various sections on the /develop/mozilla/ index
> > page. But trying to hardwire that distinction into the URI is
> > something I think would end in tears later on when modules jumped
> > from one category to the other.

>...

> What do you propose then? A generic /project? A generic /module? A
> generic /product? A generic /tech? A generic something else?
> -Fabian.

<http://mozilla.org/develop/mozilla/browser/>
<http://mozilla.org/develop/mozilla/xpcom/>
<http://mozilla.org/develop/mozilla/editor/>
<http://mozilla.org/develop/mozilla/psm/>
<http://mozilla.org/develop/mozilla/layout/>
<http://mozilla.org/develop/mozilla/editor/>
<http://mozilla.org/develop/mozilla/imglib/>
<http://mozilla.org/develop/mozilla/mailnews/>
<http://mozilla.org/develop/mozilla/netlib/>
<http://mozilla.org/develop/mozilla/chat/>

Etc. You can then categorize these however you like using the HTML
markup on <http://mozilla.org/develop/mozilla/>, but such categorization
is not hard-wired into the URIs themselves.

Matthew Thomas

unread,

Sep 14, 2001, 10:15:59 AM9/14/01

to mozilla-do...@mozilla.org

>...

Events will have happened for much longer than they will be about to
happen. Once they have happened, the page for plans will be replaced
with a page describing the event, which will be news just as much as
anything else.

In a similar way, BBC News reuses its `x is about to happen' story URL
for the `x just happened' story.

Matthew Thomas

unread,

Sep 14, 2001, 10:35:38 AM9/14/01

to mozilla-do...@mozilla.org

fantasai wrote:
>...
> List the advantages of expanding /dev to /develop.

Advantages:
* Consistent with unabbreviatedness of the other top-level sections.
* Easier to understand, especially if English (or French:-) is not
your first language.

Disadvantages:
* Four more characters to type, for those who don't use links or
bookmarks to get to it. (But *still* not as long as `contribute'.)

L. Sciarone

unread,

Dec 6, 2001, 7:30:14 AM12/6/01

to

Afzender l.sci...@chello.nl
Fabian Guisset <fgui...@softhome.net> schreef in berichtnieuws
3B9CFF62...@softhome.net...