Archive for October, 2004
No, for reals this time. A roadmap. A plan of attack, perhaps.
0.1 - Basic admin pages, shields up, small change (prevents change from showing in recent changes), SoftlinkPage
0.2 - Better pagetype implementation, permissions, wikified templates
0.3 - Better admin pages, PageCollection/hierarchy (inc. CommentPage), more RSS/atom
0.4 - Weblog pagetypes, tags/CategoryPage? (Are categories a pagetype? Dunno, I’ll have to play with it. Tags and categories will probably require the same tech as what I’ve been calling a “DynaBlog,” a page that lists out the ten most recent results of some kind of search.)
0.5 - Kept page policy, better small-change, better install, … other
Out further than that are user groups, stupid email tricks (like Jot’s magic appending to a page), and even stupider API tricks, as well as all of the possible freaky magic I alluded to in the last post. And hopefully along the way we will be making things generally less buggy, more secure, etc.
Timeframes for all this? Shut up.
October 29th, 2004
Because I’ve promised my November free time to another project, I’m going to see if I can’t get an 0.1 release of Cornucopt onto SourceForge by the 31st. That means enabling user bans and page locks (and maaaaybe IP bans but likely not), and killing that one login bug. Seems possibly doable over the weekend.
But what I’m really here to write about is something else. I’ve been thinking some more about this wikified-templates thing, and how it could lead to what you might call “third generation” wikihood.
I have, floating around in this humid little brain of mine, some thoughts as to how pagetypes are going to have to change in the near future. It turns out that, as lovely as the object-oriented model is for me to write, it’s a bit confining. A new pagetype can, as far as I know, only inherit the behaviors of one parent class in PHP 4. (Heh - you might call it a strict-father model.) So, for instance, if I wanted to add functionality to the basic Page class that added Flickr-esque tags, but I also wanted to have tags on SoftlinkPages, I would have to duplicate the tag code, unless I’m mistaken.
I’ve decided to regress, if that’s the word, to the “plug-in” model favored by packages like WordPress and Movable Type. Instead of subclassing all of the Page code and modifying or extending it, most pagetypes will just be a bunch of functions that get called when a page of the right type does its regular Page thing. This may be easier for many developers to understand.
It also opens another door: that of actually having the PHP code that makes a pagetype work… (deep breath) reside in the wiki.
Obviously, you will not want to give just anyone access to a wiki page that gets executed as PHP code. This action on my part will raise the stakes on hard security a great deal; if there’s some hole in my code that lets people fake admin access, or whatever other kind of access that has the permission to create and modify templates, then people could inject PHP code that wipes the database, destroys files on the host computer, infects the host computer with viruses, and just generally kills kittens. Yikes.
But, he said while wiping his brow, think of the upside. Imagine if extending a wiki’s functionality were as simple as clicking ‘create new page’ and selecting the ‘pagetype’ pagetype. That’s what JotSpot is after, although they are taking the (frankly much more sane) approach of a vaguely programmatic markup language. It may be that I eventually decide that I am smart enough to take that approach, or I may build some kind of extra frippery that makes editing pagetype scripts take longer, or restrains it otherwise. Or I may just give people enough rope to hang themselves; what do I care?
I really want to find a way to do this. This is HyperCard reborn, this is a revolution in waiting. I have no reason to expect that I will get there first or at all, but promise like that is the reason I write code.
I am sounding a little wild-eyed and need to be more clear about how this all follows logically from wikified templates, and about how pagetypes, pagevars and templates would fit together in this model. Watch this space.
October 27th, 2004
On the subject of what sorts of parts of the rest of the net might be useful to wikis, Corny, or both: social networking systems.
Not the ones we know and loathe today, mind you. Systems like Friendster, Orkut, LinkedIn, MySpace, Tribe.net and on and on all have inflated opinions of their own utility, and most are closed to outside use anyway. They don’t even make good use of the rest of the net themselves; they’re walled gardens.
No, the social networking systems I’m interested in 1) haven’t been built yet, and 2) will have, in true small-pieces-loosely-joined fashion, deliberately low utility by themselves. (In fact, the ones that are trying to have even a little bit more usefulness are only drawing fire for it.)
I’m thinking that external semantic social networks could help wikis form a kind of “firm security” as an alternative to hard security, keeping some of hard security’s strengths over soft, while eliminating some of its weaknesses. See, social networks are useful at validating a self-asserted identity. How do I know you’re you? Because all the people you know say that you are.
That concept alone is far from perfect, but it’s also far from as bad as you might think. Have a look at LOAF, which describes itself as an “extension to email that lets you append your entire address book to outgoing mail message[s] without compromising your privacy,” so that “[c]orrespondents can use this information to prioritize their mail.” Random email sent from someone who knows a friend of yours, as evidenced by that friend’s presence in their address book, might be more trustable than random email from someone unknown. There are holes in LOAF as currently implemented, but the general idea is pretty intriguing. Merge it with cell phones, and the Bluetooth capability thereof, and it might get hot in here indeed.
Building such a system as part of a given wiki engine would be missing the point, in my view; the point is small pieces, loosely joined. Let someone else build a general-purpose system of some sort, then don’t be so much of a not-invented-here Wiki snob that you don’t take advantage. That’s the future.
October 27th, 2004
And wikified templates! JotSpot has inspired me to move Cornucopt’s HTML templates (the HTML files, with wacky stuff written into them, that take raw CoCo-generated data and make them into web pages, via a package called Smarty) inside of Cornucopt itself, such that mere users might be able to write their own. (And such that the templates get the advantages of wiki, like a version history, et cetera.) Combined with pagevars and a helping of what B.A. Baracus would call “jazz,” this could get us almost all the functionality of JotSpot’s forms and searches. Right now, Cornucopt’s templates live in separate files, in a little folder called ‘templates’ in the CoCo file tree. This is much handier for my current purposes than having to edit them in a browser, which is why this change isn’t scheduled for a while.
Will there be security headaches? Well, you have to really trust users to let them write arbitrary HTML. JavaScript is harmful to children and other living things. IFRAMEs are just as bad if not worse. Those are the easy ones; determining exactly what subset of HTML users really need to build applications will take some thinking. Also, the searching thing really is half the battle - I may need to implement XPath the way JotSpot does to allow people to select the pages they need to. Allowing people to create pages that create other pages could get hairy, essentially becoming a flooding attack. So I’ll have to design that carefully.
Just taking the templates into the wiki is not so difficult compared to the rest of the picture. I should really make a detailed roadmap. That was kind of a non sequitur. I want to be able to do a cartwheel.
October 15th, 2004
Dammit.
Although it looks like they don’t really do customization of the overall look of the page, plus they put script in the wiki pages, which always kinda gives me a rash. I mean, I guess they have some means of keeping non-admin users from accidentally hacking the script out, or they’re aimed at intranets and they don’t care. Also they seem to cost money.
From the beginning I have been aiming Cornucopt’s app-building features with the target of admins, not users, in mind. That is, the idea has always been that the human who sets up the server will know enough PHP to hurt himself set up the ways in which information will flow, and then other users will work within that. Maybe JotSpot’s approach is better, if they have a user-perms model that’s clean and easy. We shall see.
October 6th, 2004