UseModWiki | UseModWiki | RecentChanges | Preferences

Regardless of NextRelease, the future planning of UseMod release. Don't forget UseModWiki/WhyAnotherWiki. See also the list of UseModDescendants.


SunirShah's word

Over the past couple of years, UseMod has taught me a lot about how to develop a good wiki. I've also been slowly gathering an idea of where UseMod has to go next, and it's quite a long departure from where it is now. I have just begun work on UseMod 2.0 (Dec 2002). See also RumorAboutUseModTwo

Now, what requirements have I missed? -- SunirShah

Here are the directions that it has to go in order to be a viable player on the web. Note that topics that require further discussion are listed in their own sections after this little list.

Some of us do care about passwords. My company wants a wiki on a public-facing server (we all telecommute) which is not accessible to outsiders. Others have reason to lock pages or groups of pages so that only certain people can alter them. I know these requirements go against core wiki philosophy but sometimes there is a legitimate need for them. The htaccess mechanisms supported in Apache and IIS provide for usernames and groups of usernames. It makes a lot of sense to base the UseMod password mechanism around htaccess controls. Another reason for htaccessing things is that it ensures users identify themselves (so no anonymous edits). Yet another advantage of htaccess is that NTLM authentication (not very strong but adequate for an internal network) allows users to be automatically identified by their Windows machine names (you can get an NTLM authentication module for Apache, although it's a pain to configure and needs some tweaks to be usable in some situations). And in the final analysis, why have two password mechanisms on a web server that you have to remember how to configure and use when you can have just one? --pla

Development Style

The democratization, unity in diversity, componentization, unit tests, patch simplification, public script, and communal development can all be solved with one new idea: MeatBall:WikiAsSourceControlRepository. -- SunirShah

Note that in order to be able to maintain different branches (for example a "stable and released" as well as a "bleeding edge") we really need powerful version control. It would also allow developpers to keep their own branches synchronized with the main trunk, since CVS can do intelligent merging based on common ancestors, conflict detection, and more. CVS has been around for a long time, is stable, has good documentation, various interfaces, is portable, works over the net, and hosting is available for free software development at http://savannah.gnu.org/ or http://www.sourceforge.net/. Use it. -- AlexSchroeder

While I agree that CVS is a tradional custom and good choice, I would like to try SS's idea MeatBall:WikiAsSourceControlRepository. I think it works and it is also for us an interesting experiment to seek the possibility of Wiki-like system. Actually I am not thinking of something big and not sure there will be a lot of programmers and development suggestions involved in the future of UseMod. Anyway we don't have to reach only one concensus. It seems not a problem that while using Sourceforge (or something like it), and post a patch in a wiki site. --TakuyaMurata

Alex, Wiki:YouArentGonnaNeedIt. Right now, I'm happy with my tincan source repository. As we need more complex features, it's not unreasonable to swap out the backend and replace it with CVS. Mostly, I want to do something new and exciting in open source just for the hell of it, and I don't see CVS as being more appropriate than the one hour solution I hacked together. -- SunirShah


Here is a menu. http://www.opensource.org/licenses/

Alteration of the copyright license from GPL to LGPL or even BSD. The license is really quite irrelevant if you think about it, since Perl source is published by default, but GPLing the code does not serve my goals for doing this much work as much as the LGPL or the BSD license (which are equivalent more or less when it comes to Perl). -- SunirShah

The licensing terms can only be changed all the past developpers agree, or the new script is rewritten from scratch.

Personally, I think changing the terms from GPL to something else is a very bad idea, and I will certainly oppose it for any code I wrote. -- AlexSchroeder

I second Alex. I don't see any 'decent' motivation to change GPL to something less than that. Enterprise? First, GPL allows anyone to make money from that. Second, LGPL and ones akin are considered harmful [1]. --TakuyaMurata

I want to propogate the wiki core into other web systems because I would like my philosophical principles to live on. That's one of my major motivations, and in fact that's why componentization and extensibility were the first two requirements to come to my head. That usually means giving people the code, ready made, for them to plug into their system, which usually means not quibbling over something as lame as the copyright. I prefer the good ol' days when you'd just upload code to the network and enjoy it when other people would hack on it and return you something more interesting. The GPL is very anal.

As to your other point, right now, the code is being rewritten from scratch, so I get to do what I want. If that means I get to use a weaker license than the GPL for the code I write, that doesn't affect anything you write really.

I also fundamentally think the GPL is working on the wrong paradigm because it is basically irrelevant. What protections would the GPL give over and above a simple BSD-style license? Perl is open source by definition. All the code is published. At best, the GPL would protect code authors from being sued, protect intellectual property from being stolen, and allow others to hack on the code. That sounds like a BSD license to me. Neither license even requires a MeatBall:PublicScript. I also don't know if the GPL is appropriate for a MeatBall:WikiAsSourceCodeRepository. What's the source code? Is it the output of the script generator, or each page on the wiki, or each code fragment on each page? Is the code limited to only one script generated, or all the individual interlocking scripts? The GPL is viral; I'd rather just stay away from that problem and stick with the hacking.

At least the BSD-style license is tractable. And it's not illegitimate to include BSD code within a GPL application, but it is illegitimate to do vice versa. -- SunirShah

GPL ensures the product lasts free in the future, and I can't ignore that. Lesser GPL allows software companies to make a proprientary software based on GPL'd programs and I don't like that. I don't know why you, SunirShah insists license issue is irrerivant. It is important to make sure about how the code we wrote are treated in the future. GPL has not worked well so far? But it cannot be a reason to give up copyleft. Also we have to think of the disadvantage too when the project losts GPL, that is we can't include GPL'd code to UseMod 2.0. If possible, it is a good idea to take advantage of existing code base and avoid writting everything from zero. Yes, I like to spend time for hacking not debating nutorious license issues. Stick to GPL and there is no flame. Anyway this is my point view and your mileage may vary. If I have control of the project, I sure choose GPL but I don't in this time, so I can compromise. -- TakuyaMurata

Maybe we should take this discussion to MeatBall:FreeSoftware. My input would just repeat things said on http://www.gnu.org/licenses/licenses.html#TOCWhatIsCopyleft -- AlexSchroeder

My personal preference is a BSD-style license, but the current version of the GPL is OK. In the early days of development I considered the LGPL, but much of the "library"-oriented language doesn't make sense for Perl scripts. The main reason for the current license was the GPL on the original AtisWiki, which developed into UseModWiki. (There are only a few hundred lines (at most) of AtisWiki code remaining in UseModWiki, and much of it has been heavily modified.)

Personally, I do not have a problem with people using UseModWiki as a base for closed-source development. Some time ago I even gave permission to one developer to make a commercial wiki package based on my code. (This happened before any significant third-party patches were added.) I certainly won't take extreme actions to enforce the GPL. See MeatBall:FreeSoftware for some of my concerns.

UseModWiki 1.0 will be released under the GPL. I'm not going to worry about future releases now. --CliffordAdams

The license is a political issue because it is a philosophical one. Fortunately, not all political issues need be so, um, political. First, I agree with Alex; let's move this to MeatballWiki. I'll start a list of constraints there, on MeatBall:UseModCopyright, so we can make a well-considered decision. -- SunirShah


See WikiSuggestions/ContextDiff

What about so-called GoldBar??

I'd rather separate the diff mechanism out and let people hack out a variety of diffs. I also think we need to start a diff pattern language on MeatballWiki. -- SunirShah

Mychaeel made a nice diff system for UnrealWiki , in the style of Wikipedia's -- two columns, words highlighted.

Recent Change

See MeatBall:DifferenceSuggestions


Database can be entirely rewritten using SQL, XML, CVS and such. One possibility would be to define an interface for backends to implement, where the current page database is the default backend. Note that the backend used will affect how diffs are shown.

It's even better than that. I am separating out all the different databases, like the user data and recent changes log. -- SunirShah

It would be nice if there was a DB module that gave back-compatibity with the current Use mod database system. The way that Usemod can run without any knowledge of SQL etc is one of its strong points

Unit Tests

Altering the code should be a stable process.

One step towards this would be to allow calling the script from the command line using special command line options, such that tests can run without actually creating a page database, by creating a local, temporary page database. Unit testing should not require a complete install with a running web server.


Feature simplification may also involve the removal of certain features like the administrative actions from the mainstream; these are secondary features and ones that I don't particularly care to implement myself as I don't need them and therefore cannot even understand how to improve. That doesn't mean that someone else couldn't develop them. That would indeed be the cool part of the 2.0 code as it sits today as anyone can install a new action command by just dropping a new module on the disk.

It will be the case that 2.0 is not directly compatible with 1.0. It may be reasonable to continue development of the 1.0 stream in conjunction to the 2.0 stream. My source control repository already contains a breakdown of the 0.92 script. Cliff suggested renaming the project to something else. That's a reasonable move since it's not so meaningful to claim this is a 2.0, except in the traditional compsci way of rewriting everything for 2.0 yet keeping the "look&feel". For now, I don't care as I'm hacking. ;) But once I present what I'm doing this will be an important concept. -- SunirShah

RecentChanges is one of what I call "scripted pages" -- a wiki page that's a top half of editable wiki text followed by some sort of generated content. Other pages could fall into this scheme: WantedPages? Image Uploads, the Class Wikifier I made for UnrealWiki. It would be really neat if adding more were just a question of dropping a perl script file (PageName?.pl) into a

/scriptedpages folder. -- tarquin

That's easy to do. The RecentChanges case will be generalized to allow any magic page to do something magical. -- SunirShah

Ideally, I would think pages would simply follow various templates that describe the page layout and what modules are used to generate the underlying content. Most wiki pages would follow a certain default, but special pages could be defined that would follow other templates (Home, RecentChanges, Index, others). Each template for a certain page name would define a certain module or plug-in that was used to generate the content for that portion of the page. In this case, you can just pick a diff module from a selection of ideas for diff pages, choose a "recentchanges" module, etc. Some rudimentary form support and macro language would be nice too ... for example, to make the "Preferences" page simply another template that presents user selections for which modules should be used for things like the "diff" display should the site owner decide to allow the user to change it (I'd let the user decide!). The editor and such should also be modules, extensions to the wiki markup, etc. I want it to be possible to add my spellchecker to it, as well as define output modules to generate WML markup for WAP access. -- EvanLanglois

My idea was to create a hierarchy, where the most basic page displays the standard HTML opener, site header and footer. Regular pages, edit pages, history pages, "magic pages" like RC and so forth addd more functionality progressibely. One of the ccurrent script's problems is that the header and several types of footer are grabbed from many different call points. I've made vague plans to do this in OO, but Sunir suggested that there would be other, better ways to implemetn this. (which I hope he wil share with us!) -- tarquin

Aye, that's what I'm doing. Roughly, the final result will involve something like this:

my $result .= <<EOF ;
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"/>
        <base href="$Parameter{SiteBase}"/>



The variables $Template{foo} are set by other parts of the program in any order. For instance, it's assumed that things like $Template{title} and $Template{body} are set to something interesting. Each module in the program can then have its own template if it feels like it to create content for any of the final fields, and so on in a hierarchy.

It's not object-oriented. It's far simpler than that. It's in fact global variables, just like you're taught not to use in school. ;) -- SunirShah

I have a rough script for the MagicPages. I've not yet plugged it into UseMod, but it's working as expected so far: WikiPatches/MagicPages

XHTML compliance

Mark Pilgrim has made an important point [2]. The W3C standardization process is a sham because no one upgrades to the new standards. Being XHTML compliant will not improve UseModWiki's accessibility, but in fact harm it. I'm also worried that XHTML 2.0 will just destroy everything because its goal is to be not backwards compatible. I doubt it will even be used by anyone seriously as there is a lot of legacy code out there to just abandon. I think I'm going to stick to my current set up of generating properly formed XML that renders the text correctly in IE4's (my browser of choice) HTML transitional. Maybe I'll shoot for HTML strict.

The fall out of this is that accessibility concerns will continue to eat it. I suppose we should just take each issue one tag at a time. -- SunirShah


Different messaging systems are populair on the Internet. Within a community theres sometimes good to see if other members are online. I myself has the ICQ? nr 4046787. Normally, on a webpage i paste the code: http://web.icq.com/whitepages/online?icq=4046787&img=5 into the page as an image, and everyone can see if I am online or not. (the last numer is altered, theres different design and "flowers" and signs, ranging from 1-9 I belive. This seems not be implemented in UseMod. It would be great if one would just write ICQ:40406787 and there is the flower, for everyone to see if I am online or not. UseFul?? Dan Koehl

Just add an entry to the InterWiki InterMap. In its current state it only works with prefixes, but UnrealWiki patched this... not sure if the code is here though.

maybe you are right, but I am not sure...What I mean is that this images, since its file is http://web.icq.com/whitepages/online?icq=4046787&img=5 and is not ending .gif or .jpg, it doesnt show up as a pic. Dan Koehl

You'll need to write a specific patch for that. -- SunirShah

Just add a random parameter that ends in .jpg: -- AlexSchroeder

See also: UseModDescendant

UseModWiki | UseModWiki | RecentChanges | Preferences
Edit text of this page | View other revisions | Search MetaWiki
Last edited October 16, 2007 10:32 am by MarkusLude (diff)