I see multiple webs as being a key to scaling TWiki to 100's of users. Consider each web to be an area in which to get agreement between a group of people working in a team. Amongst the team you want people to agree what terms mean, but a word (or a term) can mean something completely different to people in a different context. (This is why I prefer context to other terms for a web. Web or area don't state the intent, i.e. the reason why there should be a separate area).

I invite you to write on this topic with when having multiple webs makes sense and when it doesn't.

-- MartinCleaver - 07 May 2001

Generalised SubTopics are probably a good way of dealing with MultipleWebs type installations. ie create a group Web: DevPeople. Then create SubWebs under this. DevPeople.CompileGroup, DevPeople.HTMLGroup, etc

Of course this functionality itself is under consideration at present.

-- NicholasLee - 08 May 2001

---

New discussion starts: December 2003, refactored in from CreateNewTopic -- ArthurClemens - 10 Dec 2003

---

RaymondLutz said...

One Template per Web?: No! Template selection becomes especially important if you want to consider Webs as NAMESPACES and not a means to select the template used. My personal opinion is that Webs are generally only a superfluous complication, and that in general, there is not a concern for namespace conflict on a given TWiki site. That is, you really want to find the topic, no matter which web it is in on the site, and if you use the same topic name in several different webs you are asking for mental exhaustion. The Topic name should mean only one thing on a given site regardless of the web it is in. This is the meaning of a namespace, and therefore, the entire site should be a single namespace.

Sorry Raymond - I don't agree that Webs are redundant. Think of them not as software namespaces, rather as components. I like to have my Tasks system in the Tasks Web, and my Users in the Users Web and general discussion elsewhere. this make WebChanges and other queries simpler, and does not cause problems for my users. I would like to have GreedyLinking so that a any topic name that match links to a link (with multiple topic links displayed usefully)

-- SvenDowideit - 09 Dec 2003

I concur with Sven that multiple webs are useful on the same site.

1. They provide a unit of ownership
   • They allow a group to say "this is our concern"
2. They provide a unit of control
3. They provide a separate namespace
   • IntegrationMethodology means something completely different in management speak to in IT-speak
   • Two webs with the same purpose may need different namespaces
     1. e.g. if you run two taskforces or student teams doing the same project in parallel

-- MartinCleaver - 09 Dec 2003

To respond to the point of the usefulness of webs, let me answer with the following:

• The "canned" TWiki proposes that Webs are used for segregating pages into separate areas. The question is, why is this useful? Let's list the possibilities:
  • Create separate name spaces: Useful when you expect that there may be Topic Name collisions. In the normal TWiki distribution, for example, the concept of "Site" is an area where there is a set of users and areas where topics are segregated. I claim that for typical sites, that there is no need for separate name spaces, and that it is in fact detrimental to the usability of the system. (Note I am talking about name spaces not other reasons for webs right now) For example, I have to sign as Main.RaymondLutz. To have to say Main. before RaymondLutz is only one more roadblock to getting people to understand TWiki. Also, if you reported a bug, then is it in the Codev web or some other web? I realize that this is a historical artifact, but it doesn't mean that it is right. Where is WikiWord? In the TWiki Web, or somewhere else? Well, it depends on whose site you are in. Indeed, if you have separate groups of people, then perhaps you would like to limit the accessibility of some parts of the site through the Web mechanism, and has nothing to do with name spaces. The cases mentioned above, are actually catering to separate groups and in essence setting up separate virtual sites, I can see the usefulness of the Web mechanism in those cases... I'm not saying that it should be eliminated as a possibility, but establishing separate name spaces when you DON'T need them only adds to the difficulty of finding the right topic. As a good example, when I was first setting up TWiki, I eliminated TWiki web as there was no need for a separate name space. This is easier said than done. Throughout there is a dependency that certain things are found in certain webs, particularly in things like the site map and skin templates. Plus, having a web named "TWiki" is very counterproductive as it is not descriptive. Something like Admin or Docs would be better. (Saying TWiki is just an attempt by those who selected this name to promote that name, of course )
  • Web-Specific Settings: Webs have different settings in the WebPreferences page, such as notifications, Groups allowed to edit and view, etc. These are important, and is one good reason that webs are set up. I am for the ability to establish separate settings, but this should not be the reason to establish a separate name space. Plus, I think that many of the settings SHOULD migrate to the individual topics, or groups of topics that are segregated using other mechanisms. One of the settings in WebPreferences is the Topic Templates that are available. Without MultipleTemplatesPerWeb, you might be tempted to set up separate webs just to provide the right template when the oops page is encountered after a GO box attempt. In my view, this is the wrong reason to establish a separate web. This is the subject of this topic, MultipleWebs and is precisely my point of picking on webs.

In summary:

• web implies namespace, which is ok, but only needed in special cases in a single site. Common namespace would be better unless you actually need it.
• webs have settings which are good, but many only apply at this level and can't be reset at the Topic level, except by User topic. This is a separate discussion and is partially exposed in TopicObjectModel.
• webs imply some organization, but the simple "list of buckets" does not provide the same wealth of functionality that the rest ot the TWiki system provides. Some other organization principle would be useful within a single namespace.

GreedyLinking may be a great way to work around the difficulties. But of course, if the topic exists somewhere amongst the Greedy webs (in one TopicNameSpace), then you would want to find it with GO. But I think you can see my point that with the TWiki distribution, there is limited availability to MultipleTemplatesPerWeb from the oops page. Without improvement (if I am not mistaken), there may be a tendency to introduce webs to provide for different Topic Templates, or when other mechanisms would be better used to segregate the topics within the namespace.

Perhaps a good way to deal with this at this time would be this:

• Assume a single TopicNameSpace i.e. GreedyLinking unless there a setting is established in a web that isolates it from the others, such as in the class project case. I would imagine the canned distribution could have a single namespace.
• If isolation is desired, then select an alternate namespace for that web.
• If a WikiWord is used, it would link to any Topic within that namespace, if such a topic exists, such as from the GO box. Now, there is not a way to [GO] (without enhancements) to any web or a subset of webs. This would fix that.
• User names could be used without the Main or other prefix, to make the system more user friendly.
• Webs could continue to offer settings. I still will advocate that we have MultipleTemplatesPerWeb that are available when the user is prompted to create a new topic. And, it seems to me that suppressing the CHANGE button would improve the user experience when a form is used.
• Then, if you wish to reference a Topic in a different namespace, you can specify the Web prefix. To be safe and for backward compatibility, it is OK to use the web prefix to get to the topic if you know it. (I still have reservations about another definition for namespace, as I think the Web construct is fine. I have a problem with the organization of topics within the namespace, which is limited to settings in form fields, etc.)

An alternative direction (one that is perhaps more palatable) is to

• keep the pairing of webs and namespaces,
• provide another organizating principle within webs, for sake of a name, lets call it TopicFolders.
• A given TopicFolder would have the FolderPreferences like we have for webs now, but would be a single web namespace. A simple distribution would allow simple user names and would find commonly referred to names like WikiWord without remembering the Web they are in.
• Webs would be used ONLY for cases when separate namespaces are really needed, such as separate "Virtual" twiki sites within a single twiki install, as mentioned by others above. I hit a roadblock when I wonder how to handle documentation files that will be common to the many virtual sites.

I can see now that there are many factors and I will be willing to claim that the jury is still out, at least in my mind.

-- RaymondLutz - 10 Dec 2003

Raymond -

1. i think there are other reasons for seperating out into seperate webs.
   • logical groupings - the CodevWeb is for discussing coding issues, the SupportWeb is for support issues etc. this is not for namespace reasons and also not for WebSettings reasons.
   • for this reason i think your assertion that GreedyLinking is a way of working around any difficulties. It is just a concept because Webs are not only for namespaces. I certainly don't use seperate Webs for either of your 2 reasons at work - its just that I like (and my users seem to agree) to seperate out the Bugs / tasks from the general topics, from our coding ideas from ...... (eventually - our ISO based quality system)
2. you write too many words - i stopped reading half way as i am too tired, and wanted to respond to the first bit before i forgot it.
3. I honestly don't think that we implemented Webs to solve a namespace issue. (but then i remember arguing against Webs because i didn't think seperate namespaces were a good idea)
4. I think that Webs should not be seperate namespaces by default.

-- SvenDowideit - 10 Dec 2003

OK, it sounds like we are at least in partial agreement.

I thought of one more tid-bit that stands to support the concept of a common namespace. This is that a WikiWord which is qualified by a Web, such as

   Main.RaymondLutz

TWiki suppresses the Web qualification when viewing the page. This means that in your mind, you need to "remember" what the web is, and unless you have a great memory, you will forget if you have lots of webs. The method of display does not promote remembering as it suppresses the Web qualifier. This act alone means that there is a hint that we really need a single namespace for most applications.

I agree that there are other reasons for having a means to organize things, but Webs does too much when defining a new namespace. Yet, the term "Web" implies a single namespace.

(I will try to write less at one time.)

-- RaymondLutz - 10 Dec 2003

Multiple webs are bad for your health. They cause the wiki concept to fail when scaling to large numbers of users. I'd go so far as to say that multiple webs actually decrease the value of TWiki. Why? From experience,

1. Disjoint namespaces means multiple identical topics in different webs and lost linking opportunities
2. Users rapidly devolve to treating webs as "mine" and "yours", destroying the essential wiki democracy
3. Multiple webs rapidly become simple document repositories, specific to the reduced scope, as discussion dies. Discussion dies because the audience exposed to the content is limited to those people "interested" in that web. This eliminates much of the value TWiki had (other tools do "Document Repository" rather better).

Have a look around on this wiki; see how many lost linking opportunities, how many almost-identical pages in different webs, there are. Hierarchical webs are exponentially worse.

People will argue that by restricting the scope of a web, searches and indices and tables of contents are more meaningful, more topic related. Come on guys, we're smarter than that, aren't we? There are other ways to organise information than simply sorting it into boxes. For example, labelling (in wiki-speak "Categories"). In my single web world I can have a category "CategorySupport" and simply restrict searches to pages in that category, if I really want to. That doesn't stop any of the pages in CategorySupport also being in CategoryCodev or CategoryPlugins or CategoryBrainstorming; a single topic can be in multiple "webs" simultaneously.

The main, and only good, reason I can see for multiple webs is performance; restricting the scope of searches.

Oh, and if anyone tries to tell me that "multiple webs are required for the corporate user" - well, that's where I built up this experience, and I say they're not. Multiple webs are bad.

-- CrawfordCurrie - 12 Dec 2003

Well stated. I agree with your points. Assuming that this is a consensus opinion, it seems that some discussion about how to organize WITHIN a "Web", i.e. within a single namespace and with the various settings and controls that will be useful. Even if you are adamant that multiple webs are essential, I see no reason why this discussion can't proceed without further debate as the structure for multiple web namespaces already exists, and I am not a proponent for eliminating it, only providing an alternative within a single namespace web. I believe this should have another name, as to me, a "Web" is something with a single namespace, and should stay that way. If you must continue to use MultipleWebs, the infrastructure exists. If you want to use a single namespace, the infrastructure is lacking. This I think is the subject we are wrestling with.

We can start with some basic agreements:

• The organizational structure MUST support a single namespace, i.e. exist within a single "Web", as defined by TWiki.
• The current "Web" "buckets", such as Main, TWiki, Sandbox, etc. SHOULD be supportable within a single namespace Web using this organizational structure.

I won't go much further yet, although I have some ideas. I would suggest that the discussion stay focused on WHAT the function is and not the details about HOW such a thing might be implemented or migrated from the existing structure.

-- RaymondLutz - 12 Dec 2003

I think both of you are reaching the wrong conclusion. Multiple webs are not bad, they are like goto's, inheritance and ...

I agree however, that having multiple discussion webs will most likely backfire, but this is one, easily remembered and explained use of MultipleWebs (just like the mostly mis-used singelton pattern).

Seperating out the Configuration, Documentation, UserRegistration information into seperate Books (Webs) makes deployment and upgrading easier.

putting the BugTrackingSystem in a seperate web makes the process tracking easier (without polluting the discussion web), and similarly the SupportWeb, QualitySystemWeb and so on (this is what I have set up at my workplace)

-- SvenDowideit - 12 Dec 2003

Sven, I think you are mixing up the concept of OrganizingPrinciples with namespaces. With Webs in TWiki, the two concepts are merged. You MUST have separate namespaces to also have the benefits of the organizing principles you mention.

The proposal is to provide the OPTION to have

• an organizing principle (such as Folders, to coin a term that may not be appropriate, or Books as you use) to allow you to separate out the configuration, documentation, user registration in to separate Books or Folders to make deployment and upgrading easier,

AND

• the benefit, if you want it, to keep these in the same namespace, so you don't have to remember "Main." before every RaymondLutz so that it will find it as RaymondLutz, as an example, and you will more easily remember WikiWord links because the "Web" prefix is not hidden within the source of the page.

You can't do both of these today with the infrastructure in the release version of TWiki. If you or anyone else prefers to keep separate namespaces (status quo) and therefore force the memorization of the web names and remember different colors to denote where you "Are", then you can. (It is a very bad idea to have different "places" where the user can "be", i.e. the color of the web where you are. This was long ago scrapped as user-unfriendly by designers).

For others like me and apparently CrawfordCurrie, we will be making easier-to-user deployments that don't require a prefix of the web. The separation you mention SHOULD be possible with the Folders or Books that still use the same namespace. And, there may be times that we elect to use separate namespaces. The two are not linked and should not be considered one and the same concept. This is where I think you are making the same assumption that the designers of TWiki originally made, and does not need to be made.

Organizing Principle does not necessarily mean Separate Namespaces.

-- RaymondLutz - 13 Dec 2003

I like the idea of not having to write [Container].[Page] all the time. I also like being able to easily seperate system docs and configuration from the real wiki's contents (and hopefully one day simple unzip to upgrade like Colas argues for). If you can build that, I for one will use it. Actually even if somebody could tell me how to collapse it all into single web and namespace I'd probably do that for my public site.

-- MattWilkie - 13 Dec 2003

The devil is in the detail, Matt. I've not only had to collapse webs in a single installation together, but I've also collapsed two installations into one (ouch!). I collapsed webs together by writing a script that:

1. Ran on nominated user webs
2. Automatically put "Category<originating web>" into source topics, and created category pages as appropriate
3. Detected conflicts such as identical topic names, and flagged them for resolution

It's that "flagged them for resolution" that's the doozy. Collapsing the topic text isn't that hard; you can just concatenate them, or resolve them manually. Collapsing the history is something I never was able to solve. The other nasty was picking out user topics from the admin webs and shifting them to the user web. Anyway, I did it, and I can mostly upgrade my installations by a simple unzip.

If you have too many duplicates for manual resolution, you can always use some kind of change bars in the new topic; prefix sections with "This stuff came from the Fred web" and "This stuff came from the Joe web" or some such.

I have to make something clear; I'm not arguing with the very necessary separation of "admin" stuff - distributed help info, configuration & administration, etc. pages - and end-user pages. Aside from anything else, these topics can get in the way of the users and confuse them mightily, as well as making upgrades and content imports a nightmare. When I said "multiple webs are bad for your health" I should have said "multiple user webs are bad for your health".

Here's a way to get there from here:

1. Readonly stuff shipped with the configuration should be in one readonly web (TWiki).
2. Site admin stuff should be absolutely minimised, should only be editable by admins, and should be in it's own web (SiteConfiguration?).
3. All user topics should be in a single web (User) that is the default entry point for the average wiki user (twiki/bin/view/User/Home).

In the absence of more sophisticated slicing mechanisms, Categories work just fine; even when the user web is pretty big (thousands of topics).

-- CrawfordCurrie - 13 Dec 2003

I guess this is the old MS Outlook folders vs categories issue. Different people just prefer different things.

I believe that MultipleWebs plus the FindElsewherePlugin is sufficient to remove my concerns about multiple user webs being bad.

I like the fact that separate subjects are kept separately and are merged at run-time. This allows me to compile different merge sets (i.e. today I merge Physics with Law but tomorrow I merge Physics with Medicine and don't get all that Law stuff). Perfecting this capability makes merging two sites no different to merging multiple sets of webs.

Let's get some detail down on OrganizingPrinciples

-- MartinCleaver - 13 Dec 2003

Are you sure? (about MultipleWebs and FindElsewherePlugin)

How do you search Physics & Law versus Physics and Medicine?

What happens when the innocent punter types "MyNewWikiTopic" in the Go box? (the way everyone does CreateTopic)

-- CrawfordCurrie - 13 Dec 2003

On my http://testwiki.mrjc.com, clicking on a link to a non-existing topic or typing the URL of a non-existing topic or typing the name of a non-existing topic takes you to the same place: a "create new topic" page (http://testwiki.mrjc.com/twiki/bin/oops/Main/NextTopic?template=oopscreate&param1=NextTopic&param2=none&CGISESSID=c85ed402f8e4c3749d525ba51285876f)

Here the user can change their mind about the name of the topic they are about to create, select the parent and select the web.

The matching mechanism is best illustrated by this page: http://mbawiki.com/bin/view/MBA/WebHome . You'll note that most topics occur once, but some (such as LectureThree) occur again and again in different contexts.

I've not perfected the mechanism (there are edge cases where punctuation causes linking to fail) - I need to rewrite the TWikiDotPm's internalLink instead of having this in a plugin - but I think I am almost there.

The merging order is defined by http://mbawiki.com/bin/view/TWiki/FindElsewherePlugin 's LOOKELSEWHERE order. I've had several discussions with Colas, Michael and Peter M on TWikiIRC about this:

• http://koala.ilog.fr/twikiirc/bin/irclogger_log_search/twiki?search=RELATEDWEB&action=search&error=1

My thought is that your current web (i.e. your context) should decide whether you bring in a Law web instead of the Medicine, but this ought to be subject to normal prefs rules. (i.e. specifyable or overridable at the site, web, user or topic level).

-- MartinCleaver - 13 Dec 2003

I looked at the MBA wiki... I'm only impressed by the need for additional OrganizingPrinciples, as looking at a long list of terms in several columns does nothing for me in terms of grouping concepts or forming a larger intuitive concept. I agree that we need more detail on OrganizingPrinciples, which I will start. LOOKELSEWHERE is a cop-out.

-- RaymondLutz - 15 Dec 2003

Sorry, the columns have nothing to do with it. The words get superscripted with the web names whereever they are.

-- MartinCleaver - 16 Dec 2003

Granted, but I was just reflecting on the sort of organization you are using. It looks like you have a bunch of terms defined, and use WikiWords to define them on additional topics. Great, but it doesn't get concepts to gel. The fact that you are using several webs to "organize" these does not seem much advantage or disadvantage. I would think that a heirarchical arrangement would be great to allow you to put the terms together with other terms that are similar, and not strict alphabetical order.

-- RaymondLutz - 16 Dec 2003

heh. The only reason they are on that page is to get hits on a search engine!

-- MartinCleaver - 16 Dec 2003

Crawford, just for clarity: when you say "user" webs you don't mean just the place that holds the users' preference topics but all webs where the users congregate, Right? So to apply your stucture to twiki.org, we would have three webs:

TWiki-Docs	<= current docs as in latest release archive
Site-Config	a new web, derived from *Preferences and related topics like TWikiAdminGroup
Main	<= merged Plugins, Codev, Support and TWiki webs

Right?

The rash of new topics (e.g. GoodStylePageTooSmall, ReviseCommentDocumentation) which really belong in the support and document webs everytime a newcomer starts particpating is perfect example of the kind of problem which this kind of restructuring would cure.

See the broken link above, I've been using TWiki for years now, and I still have trouble remembering where essential topics like twiki admin group live...

-- MattWilkie - 19 Dec 2003

Matt, I started to recommend two webs, but I think that all we need to do is control the namespace situation and use most of the Web infrastructure for Folders.

Key to this concept is the ability to establish something within the Main namespace that will allow the other features of webs, but does not establish another namespace. It may certainly be easiest at this point to extend the concept of Webs to allow them to fall within a established namespace, and yet provide the other settings and perferences, notifications, etc. that are available for webs. A Q&D method (i.e. Quick and Dirty) would be to have a preference setting in a web that establishes a namespace that the web will "belong" to, which can be another named web. For example, if we want to establish "Folders" that fall into the "Main" web, such as User, Codev, Support, etc, then these could have a WebPreferences setting perhaps called NAMESPACE. You would establish the namespace web as MAIN, and then all those folders would fall into the same namespace. This would mean that you would not be able to create topics with the same name, even though they fall into different Folders. Then, site-wide settings would have a setting which is the DEFAULTNAMESPACE, and we would set that to MAIN. In fact, I see little reason not to eliminate all but one namespace, that of MAIN, as follows:

Web Namespace	Folder	Description
Main	Top	Top folder would include master WebPreferences and other meta information about the web/namespace
Main	Help	user-oriented help information, tutorials, etc., but NO "blood and guts" documentation
Main	Docs	"Blood and guts" documentation, Plugin interface, Plugins available, how to install, etc.
Main	User	current User web including user preference topics, list of Users, etc.
Main	Admin	Current TWiki and admin tools, locked to user changes, accessible only by AdminGroup
Main	Groups	Groups: Description of all groups, maybe list of users goes here.
Main	Templates	All topic templates and include topics that are infrastructure only, locked to user changes
Main	Forms	All forms topics that are infrastructure, locked to user changes.
Main	Plugins	All installed plugins, locked to user changes
Main	Codev	User discussion
Main	Support	User discussion
Main	Brainstorming	User discussion
Main	Bugreports	User discussion
Secondnamespace	Top	WebPreferences for this namespace
Secondnamespace	Foldername	arbitrary use, but a secondary namespace is generally not needed for most TWiki installs
Sandbox	Top	WebPreferences
Sandbox	User	arbitrary use, likely tests established by individual users.

Each of the named "Folders" shown above would need to have a topic like WebPreferences that would all settings to override those of the including web, in this case "Main", for example.

I think you get my drift. Note that it is actually convenient to further break up the Help, Docs, User, Admin, Groups, etc. into separate folders as long as the namespace is still singular. I guess the sandbox is still convenient as a separate namespace, but I am open to other opinions.

To do this, we can add a single setting in SitePreferences of DEFAULTNAMESPACE = Main . Folders that are defined to logically fall into the Main namespace would specify NAMESPACE = Main or perhaps we that can be assumed if another setting is not established. If no namespace were mentioned, the Main namespace would be assumed, of course, but the concept of being "in" another namespace could still be preserved, so that multiple uses of the same TWiki can still be used. However, if you wanted to have several separate name spaces, you would probably want to keep the rest of the stuff in Main. Unless you have students who are supposed to make topics with the same name, I still assert that it is better to keep a singular namespace.

Folders would be implemented the same way Webs are today, i.e. as separate directories, for convenience of site management. And, topics can be refered by two methods: Main.TopicName or Folder.TopicName . This will allow graceful interoperability with current topics that are defined the other way. We should for aliases for the Folder name so that stuff like "TWiki" could be supported if it disappears, as I have suggested. (The term TWiki is very hard to apply to just one web or folder if it also means the whole system... certain overloading of this term that only adds to user confusion.) For example, you could say TWiki.TWikiVariables or Main.TWikiVariables or Docs.TWikiVariables, for example. Therefore, another setting FOLDERALIAS could be introduced for this function.

Operation of the search and go box functions would be to first make a "search path" based on the web preferences and site preferences settings. Then, look through these directories much as is done today.

I think that with these "slight" changes, we can add a great deal of user-friendliness and flexibility, as well as providing some measure of OrganizingPrinciples other than just webs. One last thought is that it might be appropriate to allow the introduction of new Folders without significant, if any, administrative interaction.

-- RaymondLutz - 20 Dec 2003

i want to make sure that my ludite opionion is clear..... Yuck! seems to me that you are layering a more complex version of TopicClassification into something that personally i don't think is as broken as you guys are making out. It'll be interesting to see what happens when you refactor this topic into a clear 2-3 paragraph argument as to how and why i am wrong though.

-- SvenDowideit - 20 Dec 2003

Matt, I think we are reading off the same page.

Raymond, your approach would work for folders, but you are imposing another OrganizingPrinciples where the goal is to remove an inappropriate one.

Sven, see my remarks above under "multiple webs are bad for your health" as to why the current system is broken. And read OrganizingPrinciples.

Folders risk fostering the "brokenness" of multiple webs. What you have to understand is that multiple webs, and even multiple folders, are just one possible way_ of indexing topics. Unfortunately, due to the current implementation, they are a way that makes any other indexing scheme difficult (hence the need for technologies like the FindElsewherePlugin).

I'd like us to get to the point where, by default, a brand-new out-of-the-box TWiki is organised such that the end user is presented with a single namespace, and they are able to evolve their own organisational principles. At it's simplest, that means that all static stuff gets put in a static place, all modify-once, site-specific admin stuff in another, and all user inputs get directed to a third. If the local site chooses subsequently to organise into multiple webs, so be it - they can have that capability. The only "implementation" required to do this is reorganisation of the existing shipped topics. Oh, and read the proposals in StartWithACleanSlate for a similar, end-user driven, perspective that would also be addressed.

Subsequently we can think about implementation detail. I don't believe Q&D is appropriate in this case; we can do everything we want with the current implementation, albeit at a price in efficiency - searching provides everything needed to implement organising principles. See OrganizingPrinciples for more on this topic.

-- CrawfordCurrie - 21 Dec 2003

Crawford - I have been following this discussion, and have read what you wrote - i feel that you have come across a possible bad / innaproriate use of multiple webs, but that this does not show that "multiple webs are bad for your health", rather, that less than careful use of multiple webs can lead to issues that you (the twiki implementor) need to consider. Essentially, all patterns have good and badtrade offs, and this one is that it is difficult to maintain multiple discussion webs without using another pattern - such as GreedyLinking (aka FindElsewherePlugin). Many workplaces that use twiki use multiple webs successfully by segregating non-discussion webs, and other ancillary information (like the original TWiki & Main).

Also - from my discuaaions with other profressional twiki-implementors, multiple webs are one of the main reasons that the twiki has been accepted in multi-product, multi-team, multi-site organisations. There is a strong need to depricate the wiki-ness, for the sake of organisational (company) principles.

I also am puzzled as i thought that the default twiki install does have something close to the layout that you suggest we should have. 4 webs that should be used in as readonly, and then the user creates a new web for their organisations' use. I really would like to see a configuration web, where all settings willl be kept (to simplifiy upgrades), but otherwise - we're most of the way there.

-- SvenDowideit - 21 Dec 2003

* sigh * I don't think I'm getting through to you. The issue is not with webs as an organising principle, it's with webs as the only organising principle, because they make it hard to do anything else. I debated writing "multiple webs are bad for TWiki s health"; perhaps I should have, but I thought I would just try and explain why they are bad for you as a TWiki user.

Yes, webs are initially attractive to a corporate user, because they are a familiar paradigm. However, IMHO the value proposition of TWiki is not that great when pitched against competitive commercial document storage offerings, even with all the plugins. In fact, the only value is on-line editability of documents. Damping down the "wiki-ness" has made TWiki into a me-too product.

Many companies are striving to find new communication models. For example, one of the biggest battles faced by R&D companies (in the electronics world at least) is re-use. Re-use is made very difficult because project teams work in boxes; they slice and protect their information along "my web" lines. By the time a re-use opportunity is detected, development is too far advanced to rewind. By keeping information well separated, but in a shared space, opportunities could be detected earlier and acted on. I'm sure there are other examples.

There is an opportunity here to add significant value to TWiki as a management tool, by leveraging it's "wiki-ness". Corporate information-hiding principles are all very well, but there's a significant number of companies out there already with offerings that pander to these principles, and TWiki currently doesn't have the edge to make it a "must have" for companies. This is the sort of thing that may provide that edge.

-- CrawfordCurrie - 22 Dec 2003

Summarising: (always a bad idea

• Raymond wants folders not webs, in a single namespace. (Webs as namespaces, not as stored searches.)
• Crawford thinks webs are useful, but in general having a single namespace is more along the lines that users in a "mature" audience will want
• Sven likes multiple webs and finds them extremely useful.

What are webs?

1. Namespaces
2. Implicit categorisation
   • Limits discussion to that concept ( Codev.WebHome, Support.WebHome )
   • Limits search and linkage within that concept
3. A unit of systems administration
   • Managing webs, templates, skins, attachments, etc
4. A unit of configuration & state
   • WebPreferences
5. A unit of application development
   • Application webs
6. A means of allowing hosting completely independent things on the same server:
   • Resident's group
   • Story writing
7. (add more sugar to taste...)

A simple addition of a TopicClassification gives you half of 2. Automated slice & dice searching (as discussed in logically nested webs) gives you the other half.

I agree with Crawford that there need to me more ways to divide up a big namespace based on hierarchies users define, but agreed with Sven that multiple webs are extremely useful. The counter argument also holds - many groups find it natural to initially start with some application of TWiki, and then want a way of migrating to a more wiki like usage. This to me also points to the need to automagically merge namespaces in a tighter way than simple look elsewhere type functionality. (Which incidentally is extremely useful)

Indeed packaging up applications inside an application web, and pulling in look & templates from that web is extremely useful, and a good unit for distribution - since when unpacked the user can rename the web anything they like & they don't clobber their own namespace.

Bottom line, I think you're both largely right - shipping with one user changeable web (which is what Main should be based on large numbers of users' experiences) makes the most sense. Many sites will then (if they're lucky) experience a "I want one of those" situation leading to a proliferation of webs. The ability for the main web to act as a union of these subsets of the contents of the server is important for all the reasons Raymond & Crawford have mentioned.

Other uses for multiple webs and namespaces are distributed wikis - whilst often webs within a company will be shared, having a server in each geographic location with locally owned webs is a key benefit of TWiki. (OK a number of changes need to happen to take advantage of it, but it is useful) It allows a local data repository rather than on the end of a wet piece of string - making the local office more productive. Syncing just one web (or in the case of MegaTWiki), entire slews of webs & subsets local to a geography I've seen to be a pretty killer application. Having a single web (admin unit in this case) would hamper this in the general case. (When the IWOOT behaviour exhibited itself in the past I simply created a new web for the head office.I pointed edits at their server rather than ours and slaved our content off theirs. Rather than relocating everything to their server, which would've slowed everything down for local users, only the bits they'd want to change often were moved, making everyone happy)

-- MS - 22 Dec 2003

Your summary is almost right, at least in terms of my comments. Let me clarify the proposal I was making a bit.

Your summary says I want folders and not webs. Not quite. I would like to allow for both. I see valid reasons that have been presented that webs can be important is certain situations. I actually think the situations that require webs, i.e. separate namespaces are fewer than people imagine, IF they have at least one more organizing tool, what I have called Folders. Folders provide all the benefits of webs BUT are in a common namespace with some other folders, as you define. Therefore, you can have all the nice things provided for webs that are also available for folders EXCEPT the namespace does not have to be different. If you WANT separate namespaces, those are still possible. The nice thing about this proposal is that it allows for graceful migration from our current situation and organization for existing installations.

I thought about this a bit more over the last weekend, and convinced myself that this change is SUFFICIENT, and will allow for other OrganizingPrinciples. For example, if you would like to offer structured browsing, then I assert that you can provide that, without needing to further organize the method of actually storing the topic files on the server, such as through nested directories.

The attractive thing about this proposal is that you can support both the existing method of organizing (i.e. separate namespaces per web) and also you can provide a number of folders (essentially the same as webs) that are in the same namespace. Therefore, I come back to what appears to be the crux of the problem which is that there is no way to have the benefits of webs (separate settings, searches, etc) without also requiring separate namespaces.

The claim (by Crawford) that it would be best to remove an inappropriate organizing principle (i.e. webs) I generally agree with, but I am also a pragmatist and feel that it would not hurt to keep the concept of Webs, although I will probably not use it on any of the sites that I am building since I don't need the separate namespaces, and they only get in the way. Instead, I will have a single web ("Main") that will define the namespace (With the exception of the sandbox, which should probably be a separate namespace in the default installation). Then, folders will reference Main as their namespace web, and thereby share the namespace with any other folders that also declare the same. However, all the nice features of webs will be available to folders, such as notifications, settings, etc. I suggest that we away with the color-scheme (you are here) modalities that I insist are user-unfriendly. In other words, you can always find anything from anywhere, so why fool with the colors?

As a tight summary, the folders proposal:

• allows what is done today with separate namespace-webs, plus,
• allows grouping of webs into common namespaces. When they are so grouped, I am calling each one a folder.
• would find a topic in a folder either by using the webspace name prefix or using the folder prefix, to allow for graceful migration.

If you feel you don't need this, then you should not complain, as you can continue to do what you are now (Sven, for example).

If you want common namespaces, want to make it easy to find topics by name without using any web prefix, then you will support this sort of change.

I am tempted to refactor this into a proposal/syntax, etc. format, but can't at the moment due to time... Let me know if you have any further comments before we do that.

-- RaymondLutz - 24 Dec 2003

why create a new thingy called Folders when you can do the same thing by allowing Webs to optionally share namespaces?

-- SvenDowideit - 25 Dec 2003

If you look carefully at my proposal, I am not suggesting any "new thingy", but indeed are just allowing "degraded" webs that fall inside the namespaces of other webs. To make it "easy" to differentiate, I am calling these "degraded" webs that share name spaces folders. You conceptually will find the folders in a "Web" namespace, however, it also seems important that we be able to "import" from a "folder" so that you will find the names without needing the prefix, but they can be imported to multiple other webs. For example, it may be very important to be able to import the documentation and tutorials to all other webs, so it appears that they exist there as well as in their own web.

The reason I prefer to use the term folder is because to me, web implies a separate namespace, and the term folder doesn't. Folder is a term that is more appropriate for this use -- it doesn't imply too much of a new thingy but indeed, a new thingy it is, since it is not exactly what we are calling a web today.

-- RaymondLutz - 26 Dec 2003

excellent, your response makes me glad i answered with a one liner

so we want the same thing then. can we refactor this page to simply say that

we would like Webs to optionally share namespaces

because i have always disliked the tying of namespace with Web, in my mind mixing the 2 organisational concepts and calling them one thing is bad. I'd rather have Webs (your folders) and namespaces (using that word should make those who don't understand stay away from them.) The remainder of your suggestions fall into implementation details and utilities, important, but not worth diluting the above statement.

-- SvenDowideit - 26 Dec 2003

I welcome the discussion about common namespaces which is in my opinion very necessary for some time. Here my 2 €-cent :

The ongoing process of grow and restructure of wikis has to be considered. Namespaces can change from time to time and therefore methods to merge and divide namespace must be in place:

• merge webs into a single namespace: no topic name can be doubled in the new created namespace.
• divide webs into different namespaces: look in which web the topics are to make sure that if necessary a web-prefix is added to a WikiWord.

These methods are more complex than simply set the defaultnamespace within the WebPreference file but they guarantee consistent namespaces.

(Sidenote: WebPreference and all the standard web topics getting doubled when they put in the same namespace)

Further more it should be possible to set webs in more than one namespace without touch the different spaces. For example you want to make the User-Web and the Docs-Web available to every namespace but for some reason you want to separate Project-Web-A from Project-Web-B.

Maybe it is also possible to deploy some kind of subscribe mechanism to syndicate webs and their namespaces. And lets spin this idea in the future: It could even be possible to expand namespaces to webs that belong to different sites.

-- AndreUlrich - 28 Dec 2003

these days, i'm using a lot of different wiki webs and i'm not typing the web name prefix in any more. i think i've mitigated most of the problems by using the FindElsewherePlugin to locate other topics in other webs in the current installation. i've combined that functionality with the capability for SisterSites.

btw, this means i don't type in the dreaded %MAINWEB%.WikiName, Main.WikiName, People.WikiName, or whatever... I just type my name and the date

i haven't created patches for TWiki yet because there are still some issues ( for example, the SHOWWEB setting of FindElsewherePlugin clashes a bit with the behaviour from InterwikiPlugin, even more so when combined with wiki icons ). also, i have to add some code to deal with a page name matching multiple wiki webs (locally), as well as from afar. ( there is already some code which i can use/start with at http://twiki.org/p/pub/Plugins/FindElsewherePluginDev/FindElsewherePluginSuperscript.zip )

lately, i've been absolutely buried with work getting a product ready for ces (next week!). i will have some time in january to finish working on these plugins, do some more testing :), and make and post patches for TWiki. meanwhile, please feel free to try them out at http://sane-asylum.com/twiki/bin/view/Sandbox/TestTopicLogosForInterWikis, http://sane-asylum.com/twiki/bin/view/Sandbox/TestTopicFindElsewherePlugin

now that i've normalized communication between wikis (to a degree), i'd like to be able to do more page operations accross wikis ( like move page )

-- WillNorris - 30 Dec 2003

Will, the plugin approach you suggest may be sufficient to allow a unified namespace, but I am concerned that the approach used in the plugin may be focused on a quick fix as opposed to something a bit more flexible. Yet, I am happy to consider that approach as perhaps the best way to fix TWiki. However, before we do so, I would like to propose a desired operation proposal, and then compare it with the FindElsewherePlugin. Maybe, if there are features that don't exist yet, the plugin could be extended.

To this end, I am starting a new topic for this proposal and discussion, NamespaceControl. Please consider the proposal there.

-- RaymondLutz - 31 Dec 2003

raymond, does this new proposal supersceed this topic's propsal, or modify it? or what? i'm getting more and more dragged down by the sheer volume of stuff you are writing, and i honestly think you need to focus on re-editing the existing content into a unified consistent (and short) message (the summary in NamespaceControl is gigantic).

-- SvenDowideit - 31 Dec 2003

I did not see a clear proposal in this topic, and I thought that a clear proposal after all this discussion would be in order. As this topic is already pretty large, I started a new topic with a clear proposal stated. Although the actual changes to TWiki seem small, the facility of this change is large and I think, important. I refined the summary on the NamespaceControl topic to reduce the number of words. I think the focus of this topic was whether to support multiple webs or not. I am certainly in favor of supporting multiple webs, and that is not really the point. Instead, the concept is to provide SubWebs that can export their topic names to a named NameSpaceWeb.

You are right that I could have massively refactored this topic but I think it is useful at this point to leave it alone and consider a concrete proposal. The other proposal "on the table" is the FindElsewherePlugin, and we should find out if that plugin fulfills the goals of the NamespaceControl proposal. I would think that if you have an alternative concrete proposal, please present it so we can bring this discussion to an end and make the corrections we feel are required.

-- RaymondLutz - 01 Jan 2004

I have a problem with the creation of a huge amount of content and a large number of pages at proposal time, especially while there is discussion happening. this is largly due to the hard time i have been having tracking down all the topics that contain info related to the simple and small feature (DeleteAccount). I would like you to think about refactoring the content especially because you use so many words. (we all need to do more refactoring of topics..)

I have no alternative proposal - as i think your filling out of my idea of seperating namespaces and webs in NamespaceControl (the remaining topics do not add to the discussion) shows it to be an administrativly complex idea (and seeing as non-programmers have trouble with filesystem folders within folders, not great from a user point of view) that i now think it a bad idea

in many ways, i suspect that i would ignore much of what you write (due to the verbosity) (on this topic) if it were not for the fact that the things you propose worry me :()

-- SvenDowideit - 01 Jan 2004

Sven:

We have two forces at work here. Some people are asking for more detail in the proposals, while you want less detail. I don't think it is a valid request to ask for "Less detail". I have condensed what I think is a reasonable proposal, consisting of a single added WebPreferences setting. I don't claim that this proposal is necessarily complete or necessarily the best approach in its present form. I can reassure you that you can continue to work with TWiki as you have without any enhancement if you think the resulting construct is too complex. Indeed, on the page NamespaceControl, I have added a fairly complex example as a result of the request, mainly to exercise the possible capability of the construct. However, this level of complexity is certainly unusual, and is not something that most people will need, including myself. Yet, I think it demonstrates the fact that by adding this single construct, we can go a long way toward supporting other OrganizingPrinciples, and indeed should be sufficient.

Sven, if you have specific technical comments on the proposal, which is condensed into the topic NamespaceControl, please add them there. If you have an alternative proposal, make it. I don't think that it is fair to "be worried" for no reason. In other words, to vote "No", you must give a reason and allow me to address it. Just not understanding the proposal is not sufficient to uphold a "No" vote. (This is the standard voting procedure for standards bodies and development groups) Also, if you don't completely understand the proposal and you add some more questions, that will likely result in more verbosity, not less.

(BTW, I don't think this has anything to do with DeleteAccount.)

-- RaymondLutz - 03 Jan 2004

> Just not understanding the proposal is not sufficient to uphold a "No" vote.

Begging you pardon, but yes it is. If you can't get other developers to understand the basic proposal let alone the possible ramifications and bugs it's not going to get very far. (I'm not casting a vote one way or another, just objecting to the stance.)

In any case I think a succinct summary would go a long way to alleviating Sven's concerns. I could use one too.

-- MattWilkie - 03 Jan 2004

It is related to DeleteAccount, in that I have found quite a number of well discussed ideas, specs and code that have not been brought into the core, only because there was no-one in the core group with the time to notice the gems. I am not asking for less detail, I am asking for clearer and more consise writing, to increase the chance that the idea gets made into code that is used.

Unfortuanatly, I'm not even convinced that there is a problem that is not best addressed using the FindElsewherePlugin - but I am still reading parts of this topic..

-- SvenDowideit - 03 Jan 2004

Indeed, that is what is being done in the topic NamespaceControl. Remember, that not all ideas are going to be completely polished with no rough edges before they are presented... that is the true blessing of a collaboration forum like this. Making a concise summary of something using pictures and other more visual tools is feasible for me only after the idea has settled a bit. I think it is with the current suggestion in NamespaceControl.

We all have different experiences with TWiki and have different needs as well as different experience levels. As for me, I could implement almost any proposal given some time to do it. I am more concerned that we make small changes to the system so that everything can continue to run as it is, while allowing others to extend the functionality as they see fit. Since I have only limited experience with the TWiki community, I want to make sure that there is sufficient buy-in. Even if some people "vote no" because they can't understand the proposal, does not mean that the proposal won't fly with others. On the other hand, I only have so much time, so verbosity is somewhat of a result. As the old joke goes, "Here is a 10 page report -- I didn't have time to make it a 1 page report" (or something like that).

The FindElsewherePlugin may indeed be the best way to accomplish the searching portion of the problem, which has been split between searching and topic creation. The FindElsewherePlugin does not help with the creation of topics, in terms of keeping the topic names unique in a single NameSpaceWeb.

Remember, I am not set on how to implement these ideas. Perhaps FindElsewherePlugin is the best way to implement it, and if it doesn't fully do so now, maybe it can be extended.

Here are some things that I think are NOT addressed by FindElsewherePlugin (correct me if I am wrong)...

• The ability to have a set of terms/glossary topics that are common to Marketing web and its related SubWebs (say Sales and Marcomm) but NOT common to Development or Finance webs. The FindElsewherePlugin is global to the site and behavior relative to one subset of webs is not possible. That is, if you are in ANY web and you can't find it, you look through the list using FindElsewherePlugin.
• Does not help with searches in any fashion, esp. over a set of SubWebs, such as those in the NameSpaceWeb of "Marketing". As usual, searches are over the specific web or all webs.

For simple sites, FindElsewherePlugin is perhaps a very good approach. For the examples I was faced with supported per the discussions on NamespaceControl, it would need to be extended or perhaps an alternate means discovered.

I have continued to consider this and have now come full circle, reaching the conclusion that the FindElsewherePlugin is sufficient for most applications, and could be enhanced slightly for those applications that need to further control the finding elsewhere when starting in different webs. For example, the Sandbox web should perhaps not look elsewhere. This is not possible currently, but is perhaps not that important for many applications.

-- RaymondLutz - 12 Jan 2004

MS's code in OverridePreferenceSettingsInTopics provides the ability to set the skin on a per-page basis. i believe this further complicates ( in a good way ) this discussion.

• http://www.owiki.org/KwikiClueSkinSections
• http://www.owiki.org/ClassicTWikiSkinSections
• http://www.owiki.org/ClueSkinSections

sometimes a visual distinction is all that's really desired for "separation"

-- WillNorris - 15 Jan 2004

It also means that you can use that visual separaration/distiction for things like workflow. e.g. change the style of a topic while it is still a draft/proposal. Maybe it would be useful if the stylesheet could be picked up from the form, or certain values for form fields could be linked to specific style sheets.

It would also be nice if there was a way of making a style sheet from a topic so that users don't need access to the file system to add them. follow up in UsingTopicToDefineCSS

-- SamHasler - 16 Jan 2004