Work continues on the Dot update. We're in the middle boring stages now, plenty going on, but there isn't really anything interesting to talk about on that front. There will be soon, and I appreciate everyone's patience. But I wanted to take some time to talk about something relatively important. Why did I choose Drupal for the Dot?
There are a lot of other choices, and other platforms would have been easier to set up. For instance, WordPress has an excellent import feature, and at this point it's clear that it would have been easier to use WordPress for importing stories than Drupal. Also, WordPress is really all that the Dot would need right now. Multiple authors can make posts, they can be categorized, it has a nice WYSIWYG editor, etc.
But yet, I chose Drupal. I am experienced with Drupal, but even that wasn't the real reason that I chose it. I chose Drupal because it is extensible. Now this may not seem important because right now the Dot simply is a place for news posts. However, in the future I want it to be the place where the KDE community goes to talk and collaborate with each other. I think this, more than anything, is what KDE is lacking right now. There is a sort of disconnect between developer expectations and user expectations and we need better facilities so that we can work better with each other.
But even beyond that, I think that Drupal is a great direction to go in for a lot of the things related to Hot New Stuff, DXS and Nepomuk. There is a module in Drupal called services which allows web services (XML-RPC, SOAP, etc.) to be used with a Drupal installation. So wouldn't it be even more cool, if song ratings from Amarok were uploaded to a site and then aggregated together (and possibly made available in Amarok)? Or if you could upload screenshots or videos directly to a website from the KDE desktop? The possibilities here I think are limitless. It comes down to this, Drupal is the solution to having free and open web services for the KDE and Linux desktop and integrating well with web services will give KDE and Linux and edge over the competition.
Syndicate
Comments
Why not plone?
Just curious as to whether you had considered Plone (http://plone.org) as an alternative.
It's incredibly extensible, the code is quite beautiful, the community is vibrant, and the releases follow a careful schedule that keeps the developer's needs in mind.
Drupal is probably just fine for your needs, I've just found Plone to be a more polished and powerful alternative.
Thanks for all your work.
Stuart
Seems comparable
I did not consider plone as an alternative. Overall, I considered a handful of choices and then jumped into things. So far I'm pretty happy with my choice, and I hope that's the case going into the future. In retrospect, I probably should have been more transparent with this, but the gauntlet has already been thrown.
Nonetheless, Drupal and Plone seem to be in many ways very similar.
From what little I know about plone, there are a few things that stand out which I like. First, files are first class objects. This has been an annoying problem in Drupal, having files be first class objects makes Multimedia, Photos, etc. much much easier and I'm praying that this will be rectified in Drupal 7. Also, I like the fact that Plone includes a WYSIWYG editor by default (which again, thanks to usability studies, will likely be in Drupal 7). How Plone organizes content is certainly interesting, and I'm not sure if I like that or the Drupal tag methodology better.
As far as coding for Drupal, it's actually quite nice, it's more just getting over the learning curve of how do I do X. Drupal can get pretty sophisticated, especially in regards to themeing (so that _all_ output can be overridden or changed if done properly). Sometimes there needs to be workarounds for bugs (super annoying actually, and things which I need to submit patches for). But overall, I like it. _Anything_ can be modified, and I mean anything.
Also, the Drupal community is awesome. A true meritocracy. If you have good ideas and can do something with them you'll be listened to.
Release schedule wise, Drupal is usually pretty predictable. The Drupal 7 cycle is being extended, but that was from overwhelming developer consensus (and in large part because many key modules such as CCK, Views, etc. decided that the release of Drupal 6 was the signal to do full rewrites of their codebases, which again is in preparation to have them put into Drupal 7).
So, from what little I do know they seem pretty comparable, and it honestly seems like it comes down to preference. Drupal and Plone will do different things based on the different philosophies that they take towards managing content.
So in this case, it's partially preference, I know Drupal so I chose it over comparable solutions. But it's also because other KDE websites are using Drupal already, so we can move towards a standard platform. Beyond that, I know that this is something that the Drupal community can get into, so the similarity of the KDE and Drupal communities also played into it. Also I knew that the Drupal community was responsive to problems and that things would be fixed. Had it been that I started working with Plone a couple of years ago, I may very well have chosen that.
Hopefully that's a satisfying response and I think I've covered everything. Feel free to reply if you have any comments on what I've said.
Wow, that was a much more
Wow, that was a much more extensive response than I expected. As I said, if you're happy with Drupal and it does the job - have at. I've been using plone for years, and it has just gotten better and better. That and it's ability to scale for truly big jobs (NASA, Nokia, State Gov. of Hawaii) makes it my choice, anyway. Thanks for taking the time for such a complete response.
Stuart
to be or not to be on the dot
Hi Kyle,
first, I wanted to say thanks for everything you do.
As you, I think the dot should be better.
KDE deserves better :)
But, as a user, I would like to let you know what I expect to find on the dot.
On the dot, I expect to find the "official" news. I would compare it to http://www.ubuntu.com/.
When I read your post, I'm afraid you want to keep the official announcements, and add something like a "techbase forum" or something like http://ubuntu-fr.org/ (which is the french community of ubuntu users).
As a user, that's really not what I would expect because I could be confused between what's official and what's not.
But you're right when you say: There is a sort of disconnect between developer expectations and user expectations and we need better facilities so that we can work better with each other.
Maybe a "techbase forum" would be a idea. Something better than a whishes bug list (since when a wish is a bug???).
That's it.
Thanks for trying to make KDE better. Hopefully, my little contribution will help you to get it right.
Thanks again
CPDA
Dot not only for official news
I think in large part the Dot is for news about the community, and in large part is supposed to be (but the software kind of prevents this) community driven news kind of how slashdot is.
This is exactly why it's the perfect place for community features. What those will be right now I can't entirely say, but it won't be people just posting random things to the front page.
flexibility
When making technical decisions there's no reason to not give yourself some flexibility if you can.
-Ian
Drupal has crazy releases
We use Drupal for amarok.kde.org and its nice enough.
My main gripe about Drupal is their software engineering: they start work on the next major version of Drupal (eg the "break all modules" version) as soon as they finish one. So while Drupal 6 is relatively new and most modules for it are still beta, Drupal 7 already sees development.
Imagine if KDE5 was already under development and was going to be released Spring 09! Imagine how that would make all the application ("module") developers feel, let alone the users. This is the exact situation Drupal has.
Dunno if its PHP or just their (in my opinion) poor planning that makes them think they can't improve Drupal without regularly breaking compatibility. It has the effect of fragmenting their user community and leading to poorer quality modules. I personally avoid using any modules that store data as much as possible, there's a good chance that a given module won't exist in the next version of Drupal and then your screwed if you want another module thats only exists in the newer version.
It's not PHP
It's not PHP. Joomla people do it right. It's the Drupal team that sucks very badly. They close the CVS as much as they can (compare to KDE, where the repository is widely open... heck, is a version control system, so you can revert something). They do bug fix releases that break the API (YES, that's it, a release supposed to fix just a security problem, also changes the API when wasn't necessary). And they also break translations very badly in bugfix releases.
BTW, I didn't meant that the
BTW, I didn't meant that the choice of drupal isn't right. I just meant that the Joomla people do proper releases, but Mediawiki or Wordpress do it properly too. There are awful things in the way Drupal is developed, and to me, there is no clear Good Solution, but Drupal may be the lesser of all evils.
joomla
amarok.kde.org used to run on Mambo and that was pretty horrible. And Joomla! sounds like a disease. Maybe we should've given it more consideration though...
-Ian Monroe
Releases really that bad?
Dunno if its PHP
People hate PHP, I get it and I think it's a discussion that we (as in the entire development/web development community) need to move on from. If PHP is so bad then why is it so pervasive? It's not like there are no other options. There's JSP, ASP, Ruby on Rails, Django, Twisted, etc. Even though PHP isn't "pretty" I think that it does a lot of things right.
or just their (in my opinion) poor planning that makes them think they can't improve Drupal without regularly breaking compatibility
You have clearly never looked at an issue thread on drupal.org (note that there are around 250 comments). These features aren't just thrown in willy nilly.
But just looking through the changes from Drupal 5 to Drupal 6 there are definitely some clear themes. First, lots of changes to make themeing less painful, this hurts right now for module maintainers but will make their lives easier in the long run. Changes to make Drupal more database agnostic (Schema API), which really these don't even break old modules, the old style just isn't considered to be good style anymore. Changes that increase performance, and thus require modules to do a bit more. Finally, changes the make modules and techniques more consistent. Because Drupal is almost entirely implemented as modules, the module layer must be good and it means that correcting past mistakes can mean breaking a lot of stuff.
But really, even though stuff is getting started on Drupal 7, it's going to be quite awhile before it's released.
Imagine if KDE5 was already under development
Well, there has actually been some API breaking since 4.0, so I suppose you could think of KDE4.1 as KDE5 :P. But to some degree, this is simply a difference in how things are numbered. KDE stays relatively in line with Qt numbering conventions. Drupal just increases a number for every major release.
People hate PHP, I get it and
People hate PHP, I get it and I think it's a discussion that we (as in the entire development/web development community) need to move on from.
You misread me, when I said "I don't know if", I really meant I didn't know if there was something about PHP that made keeping stable APIs more difficult. I know it would be more difficult for us if there wasn't ABI and compilers keeping us honest.
I don't hate PHP at all, I rather liked it as a system scripting language before I found Ruby.
You have clearly never looked at an issue thread on drupal.org (note that there are around 250 comments). These features aren't just thrown in willy nilly.
Actually I have plenty from Google, trying to figure out why X isn't working.
I think KDE 3.0->KDE 3.5 demonstrates that you can throw in features, willy nilly or not, without breaking APIs. Its false logic to say that breaking API is required to add features.
Because Drupal is almost entirely implemented as modules, the module layer must be good and it means that correcting past mistakes can mean breaking a lot of stuff.
So there are plenty of mistakes in 6 that a Drupal 7 branch has to be opened already?
Keeping compatibility while improving an API isn't easy, but who said it was going to be. It means keeping old deprecated methods around and other nasty things. But there's good reasons for doing so.
It is a balance you have to reach. For instance, from what I hear, it sounds like Gnome is on the other extreme: they always take a while to port all their applications to the new version of a library (eg orbit vs. dbus) and make smaller incremental releases, instead of sitting down to work on big features. (This is a major debate within the Gnome community.) Drupal has gone too far to the other extreme IMO.
But really, even though stuff is getting started on Drupal 7, it's going to be quite awhile before it's released.
If I read that correctly, 18-months is still pretty soon for a library. But that's good to hear, though I still find it odd/depressing that development on 7 has already started.
Breakage in modules means API breakage
Alright, so I went on the defensive with PHP. My fault there.
Well, pre-druapl 6 themeing was pretty bad. A very large number of the changes are related to things that were difficult or impossible to do theme wise in Drupal 5.
The database changes were because of poor support for PostgreSQL in contributed modules. One of the large proposed changes in 7 is moving to PDO , to yet again, get better database support.
Most of the other changes can break things, but they're relatively small. Just a matter of updating stuff.
I think that in large part there isn't as much breakage as people perceive. Many of the large modules decided to do major rewrites that coincided with the upgrade from Drupal 5 to Drupal 6 (such as CCK, Views, etc.) because they are aiming to get them into to core for Drupal 7 (well, more or less). Because of this, modules that depend on those have been delayed, and modules that have depended on those modules have been delayed and so on.
though I still find it odd/depressing that development on 7 has already started.
Really, most developments in Drupal start quite awhile before they make it into core. The proposed database changes to 7 were being discussed even before 6 was released. Again, a lot of this is about deciding which modules go into core, and as good ideas come along that seem promising, the slowly make their way there. This is more where incremental feature development happens. Most things that get into core were pioneered in modules, not in core.
It's a different approach, but it seems like it has worked out. Drupal tries to be pretty cutting edge, that means breaking things some times.
But, bug fixes and improvements are still going into Drupal 6 (6.3 was recently released). So, it's a little bit of both.
signed
-Ian Monroe
(didn't mean to make the comment "anonymous")
Ahmed (Bassio)
Man you are reading my mind.
As someone who worked on drupal before for some months .. I see that Drupal is the natural extension of KDE for the web.
This is the power of OSS.
I think there is also an rdf module being developed for drupal which may play nicely with Nepomuk/Soprano for example. Imagine all your semantic desktop integrated with your online 'semantic web'.
The power of KDE is in integration .. which may help set this is a relatively short amount of time, and exactly as you say "give KDE and Linux and edge over the competition".
I have a question: do you think the in-development kde-php bindings will help a future kde-drupal integration or is that not related in any way???
PHP bindings for KDE
I think it will help in that sense that it will get more web developers involved in KDE, and I think that providing web services through integration with Drupal would help a lot as well. KDE needs to be extensible like Firefox is, and the more languages we can do that with, and the better they are documented, the better things will be.
As to if it will help integration with Drupal, I don't really think it will make too much of a difference. The services provided by services module are very general and really the only thing that is absolutely necessary is to have an HTTP client available, which there alread is :).