Posts filed under 'General'
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
I’ll start this (long!) post with a dirty little secret: I’ve never really been an active user of any large wiki. The closest I’ve come is having been very active on Everything2. E2 is not really much like a wiki at all, but one thing it makes a big point of, and that it does still have in common with the Wiki Way, is its status as a kind of microcosm of the larger Internet. You can’t link outside of E2 in an E2 writeup; you can type in a URL but it won’t be hot. E2’s interface affords a lot of inlinks, and its culture and original mission statement encourage users to make a lot of internal resources rather than utilize resources at other sites. If you want to link to HyperCard, for example, you throw some square brackets and link to E2’s node on HyperCard, not the more complete page on Wikipedia. The rationale is that if you want to link to a better page on HyperCard, you (or the community in general) should make a better writeup on E2 rather than taking energy off the site.
Now, efficiency is not the king of humans, nor of the network. You don’t have to be psychotic about avoiding the duplication of effort. E2 has emotional reasons for having its own pages on things (some of those reasons are rather confused IMO, but that’s not the point). That’s fine; that’s what makes communities communities. But let’s widen the focus back out to wikis in general.
The most common forms of outward linking you see on wikis are 1) plain, old-fashioned HTML links to somewhere else (sometimes visually distinguished in the read view, sometimes written with a different syntax in the edit view, and sometimes just bare, visible URLs); 2) InterWiki links. The latter are much more systematized and “wiki-like” than the former (although plenty of folks do like to bicker about the best way to do syntax for outlinks, or for links in general). In a way, InterWiki was low-hanging fruit; if there are all these other sites that run on software that’s pretty similar to yours, you just have to do a bit of coordination to have them link to each other the way they link to themselves, then all the wikis in the world are one big wiki. That’s very cool, but it’s also a missed opportunity. Why stop at wikis?
Because it’s easier, is the largest part of the reason. But the whole point is that I’m not talking about building wikis out until they do everything. (Although it sometimes feels like that is what I’m doing with Cornucopt.) I’m talking about, how do we make better use of the rest of the net? How do we incorporate the best of “small pieces, loosely joined” without sacrificing the simplicity that we showed up for?
I’ll give you an example by hopping back to E2 for a second. A year ago I was still noding now and again, hoping to finally get up enough writeups to graduate to level 4, whereupon I’d be able to C! things. C!, pronounced “ching,” is E2’s way of letting users give a special shout-out to a node and to highlight to other users what they themselves think are the best writeups in the system. You don’t get to do it until you have enough writeups to earn it, which is what the level system was all about.
So no shit, there I was, writing like a functionary, like it was a job, for a small, insular audience and towards a confused cause, because I wanted to be able to tell people what I liked. And it dawned on me: why don’t I just tell people what I like? A del.icio.us account later, I was in business, and after a couple of posts to the E2 community diaspora, others were too. In fact, if I’d used E2’s C! system, I wouldn’t have had an RSS feed, annotation, or any of the other nice stuff I have at del.icio.us by default. E2’s information architecture sets C!s up as a carrot to reward user effort, but tastier carrots can be had for no effort. E2, like wikis, tends to forget that the rest of the net is there.
So how best to use the rest of the net on wikis? Just link to the rest of the net, might be the answer of a true-hearted wikizen. Keep it simple. But the key difference between InterWiki links and other outlinks is that you don’t have to type http://. InterWiki links incorporate the central thing about Wiki: linking is easy, or easier. (You still have to know the name of the Wiki you’re going to, and that it exists, and how it’s named in the InterWiki system, at which point you probably know enough to copy and paste a URL; that’s why I like SisterSite systems better, but moving on.) Linking is part of the interface. You don’t have to do it all yourself; the software bloody well does it for you, because that’s why we have software. When you write software, it matters that you build something in, and it matters how you do it.
These issues can be extraordinarily hard to think through, which (again) is a large part of why wikis don’t bother. They have other worries more central to their philosophy. In the weblog world (and elsewhere), you see a lot of chatter these days about Web Services, and building web applications as a layer over other web sites, and something called REST and a whole lot of other nonsense. The debate over how to apply these ideas to wikis is still pretty furious, and it’s gonna be even more of a headbreaker working out how to open all the disparate pagetypes and resources in Cornucopt to effective, non-exploitative use by the rest of the net. Figuring out how to do the reverse is not so bad by comparison, although it is giving me some agita (oh God, what about multiclassing? how the hell will I do that in a way anyone will understand? what about letting end-users use plug-ins to drop in external content? will that screw me?). But at least I have a consistent philosophy of “small pieces, loosely joined” to guide me (along with the fact that, at least half the time, Cornucopt installs are not going to be very much like wikis).
E2’s objections to outlinking are well-documented, and although wikis seem not to hate it as much, their tendency to “keep it in the family” anyway reflects a desire to privilege their own way of doing things. That’s one way to think about building any software feature: it will encourage certain behaviors and discourage others. Another way is: it will enable certain behaviors and disable others. I think the latter is what you need to focus on when your mission is to see what people do with your software. The point of opening things up is not to circumvent anyone’s ideals; the point is to take advantage of network effects we haven’t foreseen, and offer more ways to do things - more tools - as well as more emergent, unforeseen things to do. That’s also the point of Cornucopt.
September 14th, 2004
I’m just going to do a little recreational sketching of the next major things to go into Corny, because I’m thinking about it, because friends are starting to suggest that they really could use it, and… hey, even though programming little spaceships is more fun than programming text fields, that doesn’t mean that programming anything is more fun than dreaming up features. So let’s go!
Permissions. I have a few bones’ worth of the skeleton of this already. The challenge is how to do the UI. I have some decent ideas on that too, but: basically, the default Cornucopt install will let the user who creates a new page not just decide what type of page it is, but decide who can use it. If the pagetype says they can choose. And if they can create the pagetype in the first place. It is all both saner and more complicated than I am letting on. Sigh.
Usergroups. A big part of what will make permissions usable is the usergroup pagetype, one of the first built-in pagetypes that will really abuse the whole concept of “type of page” (and by no means the last). By default, Cornucopt will let anybody make a group of users, and add any users to groups they’ve made. It will not do anything asinine like let you send them all messages. Usergroups will be fairly simple to start, with no real messaging at all; they’re just a way to aggregate a bunch of names when you’re writing permissions.
Admin pages. You will need ways to change all this stuff even after you’ve done it. Not all of those ways should go right onto the edit page. I already wanted to have admin pages in 0.1, but I was thinking more of the sitewide admin stuff… you know, the stuff for… admins.
Because I am dumb, I am thinking about doing these before I do these. But what I really, really need is a coding partner. Please, people; I know PHP is the language of peasants and madmen, but think of the glittering prizes. Or the menus.
September 2nd, 2004
I feel particularly guilty for having these thoughts after finally getting Corny up on SourceForge. But: does this project still matter? To me, or anyone else?
It is not an exaggeration, or a negative statement in my view, to say that when Cornucopt is 1.0, the world will not care. I had a professor who, late in the thesis process for us senior art majors, did something I thought was brave and necessary. He told us all, “This stuff doesn’t change the world. It just doesn’t.” (Wait, actually I’m remembering that line from a Steve Jobs interview in Wired. So, as far as my art prof, I’m paraphrasing, but he did say the following:) “I remember the opening of my first gallery show in the city, in this tiny gallery. I had been sort of expecting the world to beat a path to my stuff as soon as the doors opened. And when nobody came into the gallery for half an hour I actually stormed down the stairs and out into the street, like I was looking for these people. Like I was gonna go and physically drag someone in. And it dawned on me that the world really just isn’t going to notice. I had to find a way to keep doing it anyway.”
Over the years, he did get noticed… just not by the world. And he built a career. But getting there has to be about something else. It is okay to want to get noticed, even to point yourself in that direction, but you have to know that it’s going to come slowly if it comes at all. And you have to build that into your approach. Successful projects in Corny’s vein (aimed at the overlap between geeks and non-, server-based, and having something to do with moving text around and onto a website) have been built out of that classic programmer’s need to “scratch an itch,” or out of passion. (Is there a difference?)
Whether Cornucopt will ever take off is unimportant to me (right now). The question that matters more is, do I still want this code badly enough? Why do I want to have a wiki with weblogs, or anything else I dream up, floating around in it?
I only have room for one programming project in my life at a time (not counting those I get paid to do). Right now, another one is calling my name again. I think I’m going to let Cornucopt cool for a while and see what happens when I want to come back.
Sorry to keep whipsawing like this. Yes, that’s a word.
August 3rd, 2004
0.1 milestone things we want/need:
- Admin pages
- “shields up” functionality
- “small change” functionality
- verified installability out of CVS/no major bork-ups
Then we will maybe even get fancy and release a files package on sourceforge.
Oh yeah: and I would like to verify that softlinks work. They will be our first big-pimpin’ feature, the kind that lets people know we are not their father’s Oldsmobile.
July 8th, 2004
First: http://sourceforge.net/projects/cornucopt/
Yes, you can check out the tree.
Second: Powered By WordPress. I am working on the conversion details, which is why you are not reading this right now. (Note: WordPress is, regrettably, not recommended overall.)
Third: I’m pretty sure I fixed the softlink bug, but I have been so busy with points one and two that I have not actually checked. I still need something for the big-database problem, where all the miniscule little bug-fix changes get stored as full text, and I am reviewing other Wikis to see what they do. Understanding their code is difficult - hell, that’s half the reason I’m still coding this thing - so this is taking time.
July 4th, 2004
Next Posts
Previous Posts