Difference between revisions of "BurningWikiProject"

Revision as of 16:40, 9 July 2008

BurningWiki Goals

BurningWiki is a project to create a new, modular, powerful, flexible wiki CGI using Ruby. We've got some pretty ambitious goals, like a modular database backend (with multiple sources, so you could have a wiki read from a filebase and a database). CSS Skins and variable HTML templates would also be essential, as would a user-customizable sidebar. Real user logins, lockable pages (1 per user), user groups, group-lockable pages (1 per groups) are also listed in the project, but not essential.

The first thing BurningWiki needs is a development team. If necessary, I can do it all myself, but if there are other people who'd like to help out in the writing of the project, it'd be much appreciated. I'll do all the really nasty coding (the parsing loop, the database abstraction, and the CGI session and cookies) but other small parts (sidebars, general code and tasks, etc).

News

• 8/21/03 Had some rough times, but opened a BWRFC for some fundamental stuff. Please reply back.
• 8/12/03 Began the BurningWiki project page.

Request For Comments

So, I need to ask you folks about a very important part of BurningWiki. It's actually very integral to the code (which I will start writing the skeleton of soon) so I need to know how you guys feel about it.

One thing I don't like about most Wikis is the complex way you construct links from external sites. Like http://exalted.xi.co.nz/wiki/wiki.pl?action=edit&id=BurningWikiProject , it's too complex and unwieldly. Even http://exalted.xi.co.nz/wiki/wiki.pl?ElephantPunch is kinda obtuse. What I'd like to do have regular URL syntax control this:

• http://exalted.xi.co.nz/ewiki/BurningWikiProject
• http://exalted.xi.co.nz/ewiki/BurningWikiProject/edit
• http://exalted.xi.co.nz/ewiki/RecentChanges/3days

With a bit of webserver magic and some careful coding, I can make it so it feels just like you're entering files. I can even get it to ignore a trailing .htm and .html entry so you could even forget that! The problem is, with that approach, either I need to remove the idea of Page/Subpage entirely, or modify it so some subpage names are invalid. I could do complex parsing, but it might break and create confusion.

So, this better way of referencing pages (IMHO) or Page/Subpage. Honestly, Page/Subpage, to me, has always seen like a kind of a hack and a rather silly thing. Another option is to make it so subpaging uses a | symbol instead.

What do you think? (Add your vote to the list)

1. 1. Yes, new style, no sublinks: 2
   2. No! I like the old style, and the same kind of sublinks: 0
   3. I like the new style, but I'd like to see sublinks too: 2

Comments on this poll

Do you like this idea?

I like subpages; I think they serve a useful purpose, namely to lessen the need for ReallyLongAndComplicatedPageNames in order to avoid collisions, and to allow the use of more "natural-sounding" names for subsidiary pages (since they can just be /ChildName instead of something like ParentNameChildName. Part of this probably just stems from the way that I think about page organization. \\ _Ikselam

One problem with them is, I don't think arbitrary depth pages would be a good idea. Relative paths and all. However, we've seen numerous people get confused when they can't do things of arbitrary depth. Should we just bite the bullet or is there a better solution? \\ -- DaveFayram

I would like to cast my vote for subpages also, but I'm starting to dislike how difficult it is to keep everything organized. For example, do I put my stuff in Shoggoth/Artifacts, or in Artifacts/Shoggoth... well the answer depends on... well whatever I feel like at the moment. I don't know if there is a solution to this, but that is my only complaint about subpages. Of course there is redirection and all, but then... which way to redirect - again it will depend on the whim of the individual. I guess I like/hate that.  :)\\ - Shoggoth

Another vote for subpages! They are truly useful. ^_^\\ Shoggoth, I don't think its really difficult to decide whether to use Shoggoth/Artifacts or Artifacts/Shoggoth ... always link anything that is yours off your user page (i.e. Shoggoth/Artifacts is the answer). Anything you don't want to keep as "yours", de-link from your user page. Dave pointed this out to me. ^_^\\ - BrokenShade

The problem is that the content we work with (and a lot of other things people put on wikis in general) is not inherently hierarchical. For example, my artifacts could logically be stored at either Artifacts/Mapache or Mapache/Artifacts. In fact, they should be at both. Neither me nor artifacts are in any way subcategories of each other. Conceptually, my artifacts page is the intersection the set of artifacts and the set of my creations.

This would require a model where each page has a set of tags/qualities/subjects, and one can enter a combination of these without respect to order. Programatically, each page should either have a unique name or be unnamed. Each page also has a list of qualities, which are themselves page names. Entering a single name gives you that page. All pages should have both editable content and an automatically generated and updated list of links to all pages that contain that page's name as a quality. All pages also have backlinks to all their qualities. Entering a set of names gives you the unnamed page with all the entered names as qualities.

For example, my main page would be "Mapache", and would contain auto-links to all pages I have tagged as mine. The page at "Artifacts" would contain links to all pages tagged as containing artifacts. Going to "Mapache&Artifacts" or "Artifacts&Mapache" would take you to a page where I might have posted some general notes on how I design artifacts, and auto-links to all my artifacts. The page at "HygenicMoonsilverToothbrush" would contain the writeup of this awesome dental implement, and links to "Mapache" and "Artifacts", each of which also link to it. (Now, it would be nice if the "HygenicMoonsilverToothbrush" also had an auto-backlink to "Mapache&Artifacts", but doing this for all possible combinations of qualities a page has would explode very rapidly. I'm not sure how to handle that...)

Barring such coolness, I would have to vote for a simple looks-like-an-ordinary-url scheme that allowed for more than one level of nesting, though not necessarily arbitrarily deep. Two or three levels of subpages should suffice for nearly any sane organizational scheme.

-- Mapache

the transform from http://exalted.xi.co.nz/wiki/wiki.pl?action=edit&id=BurningWikiProject to

http://www.lensmen.net/wiki/edit/BurningWikiProject  can be done without modifying the code at all.
The only thing you need is a proper RewriteRule in your Apache configuration.

RewriteRule ^/wiki/edit/(.*).html?$ http://www.lensmen.net/wiki/exalted.pl?action=edit&id=$1
RewriteRule ^/wiki/edit/(.*)$ http://www.lensmen.net/wiki/exalted.pl?action=edit&id=$1

should do it, if I remember correctly. -- BrokenQuill

Suggestions

If you have a feature suggestion, please put them here in a list

• Editing Templates :: For somepages it would be nice to specify a template, to speed up common modifications. For instance, in discussion threads automatically add a separator bar and a signature.
• Specific markup :: It'd be nice if we could have an actual way of easily formatting charms and artifacts and whatnot.
• Useablilty :: The default look should have san-serif (much easier to read onscreen) - the header bars need to be aligned left - and having the copy span the whole screen also makes it difficult to read; perhaps a menu on the left? - Voidstate
  • I actually don't find sans-serif any harder to read than good old Courier or Times New Roman. I agree that all headers should be left- or center-justified, though. _Ikselam
  • It's generally accepted that sans-serif fonts are easier to read onscreen - variable CSS stylesheets would allow people to use whatever they prefer, but I do think that the default should be sans-serif, especially as there is so much text content. - Voidstate
• Some kind of time/ date stamp function was mentioned earlier today -- just from an end-user point of view, I think the ideal implementation would be an object which displays the time and date on which a specified page was last modified. I don't know about this, though. It seems like RecentChanges (and "view other revisions") already serve this purpose fairly well. It would mainly be an issue for discussion forums, if/ when we have a lot more users than we do now. _Ikselam
  • It is useful for discussions, yes, but it is also useful when checking to see if there are any new x. For instance, maybe I checked out everyone's artifact page a couple weeks ago and I want to just quickly see if anyone has added to or updated what I found last time. The RecentChanges does do this, but imagine if I've been away a couple of weeks and about 800 changes have been made since then. I'd have to hit each page I was interested in and go to the bottom to check the timestamp. I have been manually timestamping a few things, but it's a pain in the butt to do, especially if other people aren't keeping up with it. It would be nice if you could create an alternate sort of link (I wouldn't want it to be the default) that automatically showed the timestamp of the linked page. - Shoggoth
    • But I don't know if this would be much more efficient than using the method DaveFayram suggests -- make a page containing links to each of the things you wish to keep track of, then hit each one and "View other revisions" which will give the history of changes for that page only. _Ikselam
• How about a simple counter to see which pages are proving popular (users this month and total users, or something)

On this subject, BurningWiki is going to have a flexible "plug-in markup" for some kinds of text entities. Something like [;pluginame arguments] for search-replace entities. For charms I'd like to have multi-line markup. You could pass it arguments for formatting as well as data to format. In this case, something like [;timestamp SomePageName] would seem appropriate. It would also mean that, unlike the current wiki, new markup could be very easy to add, and very flexible. So yes, BurningWiki will be able to support timestamping AND the current method. Actually, BurningWiki will probably have a sidebar to watch pages you frequent and notify you if they update when you reload the page. It's amazing what you can do with cookies and sessions. -- DaveFayram

One thing I wanted to ask, either for UseMod or when BurningWiki is in place. Can anchors and links to parts in a specific page be set or could something to that effect be included in the future? I haven't really played around to check myself (mainly because I'm guessing it won't go) but I'd like it. Why? Mainly because I don't want to make page after page when I could just have one and then links to places in that page, y'know? At least until empty pages could be deleted. Don't wanna take up all your space, Dave.  :) -MidKnight

• You can't set anchors in UseMod, unfortunately. It'd be nice if you could. While we're talking about things that it'd be neat if BurningWiki could do is print a 'Date Last Modified' value for a file. I notice that, in a lot of places on ExaltedWiki, there are (last modified ... ) notes, which are useful, but have to be manually updated, which isn't a good thing. It'd be slick if there were a markup that handled that automatically [lastmodified BurningWikiProject] or something like that. - SoulToast
  • Thanks SoulToast. Figured not, but didn't hurt to ask, right? -MidKnight

Just out of curiosity... is there a reason for the name BurningWiki, beyond the obvious fact that the best way to improve anything is to set it on fire?\\ _Ikselam

Originally, it was going to be ShiningWiki, in line with the Anima flare and the fact that it would be, as a friend put it, "a shining example of what wikis should be able to do." Then one day on a long car ride as I was data-diagraming some ideas for the new wiki, Domon Kashu (of G Gundam fame on Cartoon Network) suddenly yelled, "SHINING WIKI!" in my head. Then I realized I dunno if I could take that happening more than once in my life. I switched to BurningWiki because:

1. 1. It's a cute play on the Shining thing with G Gundam (Shining Gundam got upgraded to Burning Gundam)
   2. It sounds cool
   3. It's gonna be hot, baby!

-- DaveFayram

If I might retroactively offer another logical idea for the name BurningWiki: when I originally heard the name, I immediately caught the pun of a 'burning wick,' IE working late until after the sun has set, and working by candlelight. This seems appropriate on a number of levels, given the time people invest in transcribing data into a Wiki-worthy format, as well as being reminiscent of classical authors that did much the same while producing their works. Just thought I'd note it ~Jabberwocky

Can I put in a vote for table support? It would be damn useful. -- Moxiane

Would it be possible to be able to list pages that link to a particular Wiki page? That is to say, if a particular page is linked to by say, three other pages, obscenely obscure, or what-have-you, could those three pages be noted as specifically linking to the first page? It'd be nice for maintaining link viability when Wiki locations change, without succumbing to a million redirecting pages, as well as looking for topics related to a particular page. ~Jabberwocky

I like how there's a "you failed to find the thing you're looking for, but here are similar things" thingy at Everything2.com, and that each page has a table that shows what pages link to it. It'd be great to have that kind of explicit displa of interconnectedness here. - FourWillowsWeeping

I need color and table support to take the web seriously, alas.. formatting is just to difficult otherwise. that or some kind of justification system? So much needed. Anyhow.

I think that it would be best to do everything without subdirecteries; eg each page is its own wikiword, but this would mean you can't double up on Wikiwords, which means that ultimately long complex names will be instituited - Charms becaomes GoldenDBCharms and so on, when it would be simpler for it to just be Golden\Charms\DB\

And so on. But the question becomes, do require relative or absolute linking? And I think Relative linking is the best ( /GoldenH ) and so on. this means that usernames become the only true wikiwords. But that's silly so you should allow something to be definied as a Wikiword and still maintain it's place in the hierarchy ( Have wikiwords reference to the absolute path, but not require absolute path markup? Maybe by putting a question in front of it, like, ?Charms ?)

Anyhow there's a lot of thigns you can do but I don't think the progression towards InsanelyLongWikiWordsThatDoNotMeanAnything is necessarily a good thing for the internet as a whole... -GoldenH

Congrats on the job, Dave!

I'll pass on some implementation two-cents.

• Look into cross-compiling gcc from your computer to your host, if you need it. It's how I got Ruby going.
• The database back-end is wonderful. I recommmend separating the Content Table into two pieces, one for content metadata, and one for the content history. But you probably already did that, Pragmatic Programmer good!
• Amrita, ClearSilver are good examples for developing templating systems.
• Read the dense XUL and XBL white papers at www.w3c.org .
• Use Ruby. ;)

For my project I used the following schemas:

• USER: UID, NAME, PASSHASH, EMAIL, IP, PROPERTIES, PREFERENCES, GROUPS
• GROUP: GID, NAME, MODERATOR, PASSHASH, MEMBERS
• METAPAGE: PID, PATH, PERMS, CREATE_STAMP, OWNER
• PAGEDATA: PID, REVISION, MINOR, TIME_STAMP, CONTENT, EDITOR

Hope that gets some ideas flowing. See if you can tell how I serve images.

As far as skinning and style sheets go, the system combines style_defaults, user_style, style_override heirarchically.

Good luck!

-Chemdog

Just a thought here, and I know absolutely nothing about coding so I could be talking crap, but could you make it so that a page was defined by it's address in such a way that GoldenH/Charms/DB would give the same page as Charms/DB/GoldenH and could you make it so that the Charms page could link to all pages containing Charms in their address? - CorlanDashiva

If this topic hadn't pretty much died, I'd say that's a great idea, actually. -- GreenLantern

Just saying that I added a vote for "New style + sublinks" - medivh

Team

If you'd like to be on the BurningWiki team, email me.

• DaveFayram
• Voidstate

[1]