On 3/11/06, felix winkelmann <[EMAIL PROTECTED]> wrote: > Speaking of wikis: I've put together yet another feeble attempt of writing > web software (boy, am I modest, or what?) at this place: > > http://galinha.ucpel.tche.br/coop > > It's a regular wiki, currently with a rather llimited set of editing > commands and it uses some homegrown markup. I could have used > Alejandro's excellent stream-wiki, but the idea is to provide a simple > to process internal format, since I'd like to support programmatic > access (via some HTTP-based API, or even by allowing sandboxed > Scheme code - I'm not sure yet).
Is that why the syntax is different? I agree that it's a good idea to support programmatic extensions somehow. Is the source available? I've been working on a wiki too, based on Alejandro's stream-wiki. I don't have anything worth sharing yet, just getting started but I have lots of ideas. I am most familiar with MediaWiki (from the perspective of using it, haven't done much hacking on it) so I'd like to have most of its features and then some. Most wikis leave room for improvement in how they handle images. I also want to have full version-control like MediaWiki does. svnwiki seems good but I think I will take a different approach rather than depend on subversion. (So far I'm leaning towards a fuse-based filesystem which does version control, which I may end up having to write; we'll see. I found something called wayback which seems to be a good start.) I don't like how most of them depend on a relational database, and serve every page by doing a database lookup and then dynamically generating the page. Mine will generate static pages, and be dynamic only (or mostly) when you are editing. So that should be really quick, but I wonder if it's better to use Spiffy for everything, or try to have Apache or a kernel-based httpd serve the static pages and delegate the dynamic stuff. I haven't done anything with fastcgi or scgi yet so am not sure what the best approach will be. I will probably just stick with spiffy until I get the features fleshed out more. Another feature (which might or might not be a good idea) is to have folders, rather than a single namespace. A problem arises when you try to use a conventional wiki for multiple projects - you have to be careful to choose sufficienty verbose titles for the pages, so that you don't use up all the good names for one project. So I think I will make it possible to partition parts of the wiki in actual directories on the server. That way different directories can have different permissions too. At work, we used mediawiki for a while, and then pretty soon people wanted to have some stuff be public, and some be private to our department, and we didn't find a way to do it. So we had to make the whole thing private (using a .htaccess file). What does Spiffy have for security? An alternate approach (rather than directories, to avoid namespace crowding) would be to use machine-generated names for the pages so they are guaranteed unique. And then you need a richer UI for creating the links, so you don't have to type in long numbers. This gets into Xanadu territory. _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
