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.
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
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
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.
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
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:
![[Home]](/wiki.gif)
my $result .= <<EOF ;
$Template{header}
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"/>
<html>
<head>
<title>$Template{title}</title>
<base href="$Parameter{SiteBase}"/>
</head>
<body>
$Template{logo}
<h1>$Template{banner}</h1>
$headerRule
$Template{body}
$footerRule
$Template{footer}
</body>
</html>
EOF
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
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
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