KDE Dot News: FootNotes Goes Drupal
As some of you might know, KDE Dot News initially started off as a clone of the now-defunct GNOME Gnotices site.
In principle, Gnotices was a great idea that worked spectacularly well for the GNOME project -- at least at the beginning. Whereas KDE news had been a painful process with typically only one person taking the initiative to manually update a static webpage, Gnotices demonstrated that project news left in the hands of the "unwashed masses" could handily beat a one-man show, no matter how good the intentions of the latter. The key was evidently adequate infrastructure.
In the end however, Gnotices suffered from severe editorial neglect, and when the GNOME community turned hostile and grew rebellious, Gnotices took a turn for the worse. The site was harming the GNOME project and the webmasters decided to put their foot down. Severe restrictions were implemented on the site but it never recovered. The restrictions just made matters worse and made GNOME look even more neglected. Gnotices dropped off the net altogether and was eventually replaced by the independently managed FootNotes site, with a less than stellar transition.
In fact, it seems that the GNOME website has gone back to the dark ages. It seems hardly maintained (no news of GNOME 2.8.1?) compared to the old days where, although it looked amateurish, it was vibrant and alive because the community made it what it was. I reloaded it every day. Mind you, I'm not saying the designed-by-committee KDE frontpage doesn't suck in its own right (oh! I can theme it. sometimes. oh CSS! such joy!), but at least the content is there, always fresh, and people like Steve still care for it.
KDE Dot News was based on the same technology as Gnotices and consequently followed some of the same principles, but, in contrast, the dot has always had a stronger editorial and admin presence. The same crowd that attacked Gnotices did sometimes come over to KDE Dot News but attacking us tended to be more of an uphill battle, with diminishing returns, such that matters have tended to stay under control. Furthermore, our growth has been nothing like that of Slashdot, so personal attention remains possible without having to resort to ugly discriminatory hacks such as a mob moderation system.
I was happy to choose Squishdot/Zope at the time because the interface was so simple, so easy, yet so effective. Although it did and still has limitations and bugs, it really was "good enough" and for the near future still is. I believe the dot design is in principle very clean and very effective, to the point that some of the limitations grow on you and even start masquerading as features (e.g. lack of formal user accounts). I'd like it to stay this way as much as possible and it will.
Yes, to give credit where credit is due, we all blatantly stole ideas and designs from Slashdot.
Unfortunately, the dot has problems -- problems that grow worse day by day. As simple as Squishdot is, it perhaps owes a lot of that simplicity to Zope. Not surprisingly however, Zope is no simple beast. Zope is powerful, fantastic for rapidly developing a site and exploring possibilities, but maintaining it or trying to understand it for the purposes of optimisation isn't a trivial matter if you don't have proper resources.
To pick an example, the database grows larger every day and gets slower and slower until it is "packed" -- and then the process just starts over. This is partly due to the implementation of Squishdot but trying to solve the problem always involves having to deal with the complexity of Zope or, worse, attempting to bypass it by using external resources. I may be naive, even proudly so, but something that aspires to the simplicity of the dot shouldn't have to depend on something of the complexity of Zope.
Havoc always used to say you could trivially solve the Zope problem by throwing more RAM/CPU/disk at it, but in truth we depend on the kindness of friends (such as LeVillage.org) and we owe it to our friends not to abuse that kindness.
(Incidentally, I think Havoc's rant on Python is right on the money. I hate it that stuff like the obvious "help(File)" doesn't work in Python and searching for its documentation is ridiculously hard to a newbie because you have to know "File" is indexed under "built-in types". At least, that was the case for the old version of Python I'm using for the dot.)
So I'm looking for solutions. I have big, vapourous, ideas that will not be realised within the next four months, not until I'm out of school (and, hopefully, safely at Google) but that I'm determined to see through.
I was therefore quite fascinated to learn that Stro had problems of his own with FootNotes. The main problem seemed to be the beast that is MySQL, which was apparently faltering in a similar way to the Zope DB. Essentially, PHP-Nuke was abusing MySQL almost as badly as Squishdot is abusing Zope. The solution for Stro was to move to Drupal.
I have to admit, I never really liked FootNotes. The site was complex, ugly, buggy, (and slow, though easily faster than the dot) and the content was often, in my opinion, just as poor as the old Gnotices site, often consisting of minor app announcements and the such. Not very elegant at all, and the GNOME project doesn't really give it much visibility or credibility.
The transition does pique my interest though. What was particularly nice was that Stro converted all the old PHP Nuke articles and comments over to the new structure, a touch and a sign that he cares and is competent. This time, GNOME content and history didn't drop off the face of the planet as it did with the Gnotices to FootNotes transition.
Drupal looks vastly simpler than PHP Nuke on the surface and FootNotes seems to benefit automatically. The URL structure looks fairly clean and it seems straightforward to maintain link compatibility with PHP Nuke, although Stro hasn't done this yet.
On the other hand, Drupal still has its bugs and weaknesses. KDE Developer Journals, based on Drupal, never remembers logins and the new FootNotes is no different. This is incredibly aggravating but apparently nobody cares and the bug has survived in Drupal/PHP for many months. Further playing around, the thread display controls seem badly broken and ineffective. And I hate that stupid PHPSESSID variable that appears in the URL from time to time.
There are some features on the dot that don't seem to be present on Drupal, so it might require modification. And if I'm going to move the dot to a new CMS, near-total backward compability will be a primary requirement and the dot's existing hierarchical structure must be maintained. This might be possible with Drupal but might also be against Drupal's "one SQL query" philosophy. Even if it could be convinced to do otherwise, we'll probably end up with the same MySQL performance problems as PHP Nuke. Speculation.
I have done some digging on MySQL, and drawing from my own admin experience of it (both KDE Wiki and KDE Forums use it), I'm not at all keen on transitioning from Zope to MySQL. And from what I gather, FootNotes/Drupal/MySQL is still quite resource intensive.
It'll definitely be interesting to watch the evolution of FootNotes and learn from Stro's experience.
So, yeah. So there.
In principle, Gnotices was a great idea that worked spectacularly well for the GNOME project -- at least at the beginning. Whereas KDE news had been a painful process with typically only one person taking the initiative to manually update a static webpage, Gnotices demonstrated that project news left in the hands of the "unwashed masses" could handily beat a one-man show, no matter how good the intentions of the latter. The key was evidently adequate infrastructure.
In the end however, Gnotices suffered from severe editorial neglect, and when the GNOME community turned hostile and grew rebellious, Gnotices took a turn for the worse. The site was harming the GNOME project and the webmasters decided to put their foot down. Severe restrictions were implemented on the site but it never recovered. The restrictions just made matters worse and made GNOME look even more neglected. Gnotices dropped off the net altogether and was eventually replaced by the independently managed FootNotes site, with a less than stellar transition.
In fact, it seems that the GNOME website has gone back to the dark ages. It seems hardly maintained (no news of GNOME 2.8.1?) compared to the old days where, although it looked amateurish, it was vibrant and alive because the community made it what it was. I reloaded it every day. Mind you, I'm not saying the designed-by-committee KDE frontpage doesn't suck in its own right (oh! I can theme it. sometimes. oh CSS! such joy!), but at least the content is there, always fresh, and people like Steve still care for it.
KDE Dot News was based on the same technology as Gnotices and consequently followed some of the same principles, but, in contrast, the dot has always had a stronger editorial and admin presence. The same crowd that attacked Gnotices did sometimes come over to KDE Dot News but attacking us tended to be more of an uphill battle, with diminishing returns, such that matters have tended to stay under control. Furthermore, our growth has been nothing like that of Slashdot, so personal attention remains possible without having to resort to ugly discriminatory hacks such as a mob moderation system.
I was happy to choose Squishdot/Zope at the time because the interface was so simple, so easy, yet so effective. Although it did and still has limitations and bugs, it really was "good enough" and for the near future still is. I believe the dot design is in principle very clean and very effective, to the point that some of the limitations grow on you and even start masquerading as features (e.g. lack of formal user accounts). I'd like it to stay this way as much as possible and it will.
Yes, to give credit where credit is due, we all blatantly stole ideas and designs from Slashdot.
Unfortunately, the dot has problems -- problems that grow worse day by day. As simple as Squishdot is, it perhaps owes a lot of that simplicity to Zope. Not surprisingly however, Zope is no simple beast. Zope is powerful, fantastic for rapidly developing a site and exploring possibilities, but maintaining it or trying to understand it for the purposes of optimisation isn't a trivial matter if you don't have proper resources.
To pick an example, the database grows larger every day and gets slower and slower until it is "packed" -- and then the process just starts over. This is partly due to the implementation of Squishdot but trying to solve the problem always involves having to deal with the complexity of Zope or, worse, attempting to bypass it by using external resources. I may be naive, even proudly so, but something that aspires to the simplicity of the dot shouldn't have to depend on something of the complexity of Zope.
Havoc always used to say you could trivially solve the Zope problem by throwing more RAM/CPU/disk at it, but in truth we depend on the kindness of friends (such as LeVillage.org) and we owe it to our friends not to abuse that kindness.
(Incidentally, I think Havoc's rant on Python is right on the money. I hate it that stuff like the obvious "help(File)" doesn't work in Python and searching for its documentation is ridiculously hard to a newbie because you have to know "File" is indexed under "built-in types". At least, that was the case for the old version of Python I'm using for the dot.)
So I'm looking for solutions. I have big, vapourous, ideas that will not be realised within the next four months, not until I'm out of school (and, hopefully, safely at Google) but that I'm determined to see through.
I was therefore quite fascinated to learn that Stro had problems of his own with FootNotes. The main problem seemed to be the beast that is MySQL, which was apparently faltering in a similar way to the Zope DB. Essentially, PHP-Nuke was abusing MySQL almost as badly as Squishdot is abusing Zope. The solution for Stro was to move to Drupal.
I have to admit, I never really liked FootNotes. The site was complex, ugly, buggy, (and slow, though easily faster than the dot) and the content was often, in my opinion, just as poor as the old Gnotices site, often consisting of minor app announcements and the such. Not very elegant at all, and the GNOME project doesn't really give it much visibility or credibility.
The transition does pique my interest though. What was particularly nice was that Stro converted all the old PHP Nuke articles and comments over to the new structure, a touch and a sign that he cares and is competent. This time, GNOME content and history didn't drop off the face of the planet as it did with the Gnotices to FootNotes transition.
Drupal looks vastly simpler than PHP Nuke on the surface and FootNotes seems to benefit automatically. The URL structure looks fairly clean and it seems straightforward to maintain link compatibility with PHP Nuke, although Stro hasn't done this yet.
On the other hand, Drupal still has its bugs and weaknesses. KDE Developer Journals, based on Drupal, never remembers logins and the new FootNotes is no different. This is incredibly aggravating but apparently nobody cares and the bug has survived in Drupal/PHP for many months. Further playing around, the thread display controls seem badly broken and ineffective. And I hate that stupid PHPSESSID variable that appears in the URL from time to time.
There are some features on the dot that don't seem to be present on Drupal, so it might require modification. And if I'm going to move the dot to a new CMS, near-total backward compability will be a primary requirement and the dot's existing hierarchical structure must be maintained. This might be possible with Drupal but might also be against Drupal's "one SQL query" philosophy. Even if it could be convinced to do otherwise, we'll probably end up with the same MySQL performance problems as PHP Nuke. Speculation.
I have done some digging on MySQL, and drawing from my own admin experience of it (both KDE Wiki and KDE Forums use it), I'm not at all keen on transitioning from Zope to MySQL. And from what I gather, FootNotes/Drupal/MySQL is still quite resource intensive.
It'll definitely be interesting to watch the evolution of FootNotes and learn from Stro's experience.
So, yeah. So there.
posted by Navindra Umanee at 01:30
7 comments
