BlogBlog is just an idea at this stage. It's mostly in GarthKidd's head.
BlogBlog is a small superset of MoinMoin. The differences are so minor they might end up rolled into the MoinMoin code if JürgenHermann thinks my code isn't a toxic pollutant to be shipped only as separate patches.
BlogBlog hopes to combine WikiNature with BlogNature and PicoNature.
To summarize each aspect:
WikiNature says you've got to be able to carve the web site from the inside out -- if you were ever a MUSH or MOO user, think "@dig") -- rather than have to sculpt it from the outside or, worse, word process it.
BlogNature says you keep people up to date by appending to to the top of things.
PicoNature says you discuss things by appending to the bottom of them.
I need BlogBlog for DeadlyBloodySerious, my web site. Don't bother going -- there's no "there" to go to, which is the real problem. I have no intention of using <ptoo!> MsFrontPage, and I'm addicted to the ease of use of Wikis, so there you have it.
Progress so far
I've started on breaking the monolithic Page and User classes up into separate layers of objects; one to handle storage, another to handle core logic, and another -- maybe to become several -- to handle presentation and interaction with the user. This is required so that I can have swappable storage and interfaces, but it's thrashing the code around so much that I can't see BlogBlog being anything but a fork at this stage. If anyone can figure out an alternative ("Here, Garth, I know you're a complete newcomer, but howabout we hand you core development of MoinMoin for a while?" strikes me as a tad unlikely), please let me know.
Fork and -- later, if it makes sense, if my code is clean, etc -- merge back. Who knows?
Well, talk about you changes, and I can tell you if they make sense -- and if they do, I will take them back. An abstraction layer for the storage was planned anyway, in order to optionally use a database. A pre-requisite to any changes to the main code is that easy setup and none to little dependency on 3rd party packages is kept. -- jh
Well, the first thing I did was rip all of the methods related to storing users and pages into a UserStore and PageStore class, those being acquired from the storage/ directory in the same way macros are handled. Change a configuration variable, and GetPageStore() and GetUserStore() return an instance (well, the instance -- they're singletons) of the appropriate classes. Things slammed to a halt when I realised I'd also have to break off the logic of users and pages away from the web interface to them (in turn, so I could switch front ends, support XML-RPC, etc). That seemed like an awful lot of code reorganisation to submit as a patch.
As far as the third party packages are concerned; looked at WebWare? Easy setup is a given. My config.py supplies more defaults, but is easy enough to deal with. -- gtk
Why pick on MoinMoin? Consider the alternatives:
Duplication
I could spend a lot of time duplicating MoinMoin's code. Not only would that be a complete waste of time, but any nifty enhancements developed for either MoinMoin or my hypothetical collection of code would probably not be portable to the other.
Fork
I could take the MoinMoin code and build on it, but otherwise cling to my implementation and not let anyone play with it. That seems pretty childish.
I think developing it in my spare time and submitting patches ad nauseam is a decent enough way of doing things. I'm sure you'll comment if you disagree.
Unsorted natterings about how to implement BlogBlog in MoinMoin:
- The first requirement is subitems. Both blogs and topics can be implemented as items with incrementally numbered subitems.
How to implement subitems: subdirectories! If we need a subitem in BlogBlog, for example, we move BlogBlog out of the way, create a directory called BlogBlog, and rename the old BlogBlog as BlogBlog/0.
- Subitems can also be used to group items together quite nicely.
- A natural inhibitor against people getting too silly with nested subitems is that nobody will ever link to them because too much typing will be involved.
- Two main differences between blogs and topics:
- By default, topics can be posted to by anyone.
- By default, blogs can be posted to only by their owner.
... which brings me to the concept of ownership and security, two words you don't often hear associated with WikiNature except in a negative manner. I'm going to be using this for my web site, and I don't want anyone but me mucking with the front page or my blog.
If you hate security, turn it off. Insecure should be the default, given that this is still a WikiClone.
Ownership and security require metadata. That can be difficult to maintain when there are multiple processes hitting the same data files. I guess I'll just have to figure it out anyway.
- Whether people can spark discussions off discussions is a bit contentious. That's threading! Eep! On the other hand, Wiki users are accustomed to being able to comment on pretty much anything, and being denied that opportunity will be somewhat jarring. There's a way to resolve this:
- Bidirectional link tracking. Template permitting, I'd love to see a sidebar listing which items point to the item I'm looking at. Even if the item I'm looking at is protected somehow, other people can still draw my attention to their comments on it simply by commenting on it from wherever they can do so.
- Another difference between blogs and topics:
- You have to make an additional effort to skip postings to topics.
- You have to make an additional effort not to skip postings to blogs.
- The main reason for this is that blogs are upside down. Do nothing else, and you'll only see the more recent stuff. Do nothing else when visiting a topic, and you'll see the next few postings after the posting you last read.
I'll want to wedge an abstraction layer in between MoinMoin and its storage (currently implemented as flat files in a directory) so that I can base things out of a database.
- This isn't a huge priority, as I suspect this is more prejudice than neccessity.
- ... except for the metadata. Oops.
MoinMoin itself makes this pretty easy. Patching up the macros will be more difficult. Not to worry.
- This isn't a huge priority, as I suspect this is more prejudice than neccessity.
I've been thinking about this one too. Could it just be a macro? If you had pages that we're say like NewsBlahBlahBlah and then have a macro that would grab all the news pages, sort them by date, give them a SlashDot like snippet of the first paragraph? PicoNature seems to me to be a disciplined ThreadMode. We've been doing pages with DocumentMode at the top and ThreadMode at the bottom which seems a bit to me like PicoNature. Seems like we just need a way to have the articles sorted and we're away. Whaddya think? -- BruceDurling
Indeed there is no need to rip apart core code for this type of pages. What you can also do is introduce a new format (i.e. a new parser) that generates a page containing "add an new item" links together with the page content itself. The only change to the core (which I would do) is the ability to totally remove or at least redirect the "EditPage" link at the bottom, by some calls in the new parser. And btw, you can also store the single news items in a database, and only keep the meta information on the Wiki page proper. Or, alternatively, show the Wiki page normally (containing some hints about the topic of that news page) and then append / prepend the DBMS stored news items. -- jh
How suitable would the way PikiePikie (http://pikie.darktech.org/) handles WebLogs be for MoinMoin? Looks to me like a new macro and then everything is in a different directory.
Here is a quick blurb about it from the Implemented Pikie Enhancements:
Added support for multiple WebLog's. Any page containing macro WebLog causes a subdirectory to be created based on that page's WikiName, and WebLog entries are stored in the subdirectory. When the page is displayed the subdirectory's files are sorted and displayed as a list. See WebLog for further details and a description of extra functionality available in some WebLog implementations.
-- BruceDurling
That's certainly getting there! I'd want the objects to be subobjects of the root of the blog, I'm still a bit fixated on unWiki security, and I'd want to be able to turn it upside down to use it as a conversation object, but it's a start. -- gtk
I have been watching and waiting various wiki developements hoping that this would get worked on. Currently I am running MoinMoin because I like it the best but some form of WikiLog support would be wonderful!
-- AdamShand