Slashdot Mirror
Should Open Source Content Management Interoperate?
bergie writes "Advogato is running a thought-provoking article on whether open source content management systems should interoperate. This is a big question involving social issues inside the projects, but also promising huge benefits to developers deploying open source CMSs and to desktop projects like Mozilla, OpenOffice and Xopus wishing to connect with a collaborative backend. This discussion will also be a major topic on the upcoming OSCOM conference."
Drupal is an open source content management app run by sites such as DebianPlanet. A couple of examples: if you have a Jabber account, Drupal can authenticate through XML-RPC and through a Jabber server. Also, Drupal allows for utilization of the Blogger API for the posting of content.
Why can't WebDAV be the standard? From what I have seen WebDAV has a lot of the needed functionaility for a CMS. Jakarta Slide (Open Source Java CMS) is implementing WebDAV as their foundation.
(BSD's 4.2 TCP stack is in both windows 2000 and WinXP). Please correct me if I am wrong.
That is a fallicy. The truth is that the original version of WinNT contained a third party TCP stack; it turned out the people they bought it from stole it from BSD. The stack was then re-written.
The credit to the regents of the Univ. of Calif. in the Windows readme file is for the simple tcp/ip unix utilities (ftp, telnet, finger, etc) which are bsd code to ensure compatibility and similarity for unix folks when using the commandline on a windows box.
It is a great concept.. have a common API for posting / retrieving content, for posting comments, etc. But getting people to impliment it would be like pulling teeth. Everyone would think that the way they are currently doing it is the best way. This is one downfall of Open Source, the "ego factor".
The "ego factor" is the same reason we have 5 different office products all working on seperate import / export filters for MS Office, when the effort should be combined.I cannot comment on the specific articles because even Google cache is slashdotted right now.
Anyhow, the idea that web content, file management, and databases are all different things should perhaps be challenged.
Hierarchical file systems are too rigid IMO, databases charge fat bucks for document management, and web content managers assume that the web world is an island away from other company activities.
I suggest ways be found to combine all these. XML is not the answer because it is linear: you can't "index" by an aspect or relationship not covered in an XML file layout/hierarchy. (If you could, then it would be a database and not an XML file, per se, and nobody has shown that an XML database is better than a document management database or a relational database or whatever. Besides, XML is an exchange format, not really a good storage format.)
Basically, everthing can be reduced to 2 things: "documents" and "attributes". Relational databases do a pretty good job at attribute management [1], but not document management, at least not without addons.
Thus, we need to find a standard protocol for referencing and querying a "big pool of data" based on documents and attributes. Then "content databases" can be built.
[1] There is kind of a mini battle between "defined attributes" and "open-ended" attributes. RDBMS tend to want to know field names in advanced. But it does not have to be that way. But, there are pro's and con's to each approach, defined attributes usually result in better performance, but make it harder to add new fields not anticipated in advanced.
Table-ized A.I.
I massively disagree. This article is the stuff of frustration. And I agree with them. As an old corporate guy I've been watching the various open source content management systems for years and to me they *all* look like muck.
Specifically, they look like the work of a bunch of programmers who have never for a moment on their lives run or even worked in an actual content creation environment. They program in the features that are "cool" to implement instead of what an actual publisher could use.
So they're finally talking about how poorly an aspect of this whole movement functions in the real "I need to make a living with this" world and surprise, surprise, it sucks so bad that the room is filled with (heh, heh) jabber, in which they can't even agree on what they're arguing about or what goal they're seeking.
This all looks promising to me but frankly I wrote this whole category off years ago. As far as I'm concerned the dedicated content management systems that are available or well on the way now are VisiCalc in a world where most of us need Excel. I. e., this is all very nice but I'll wait until they've putzed around for a few more years, have worked out the most egregious mistakes, and start over from scratch.
BTW, if any of you ever want to check out a *real* content management system, you know, one that complex pubs (like the New York Times, Time Magazine, JCrew, etc.) actually *use*, then study the feature list, UI, etc. of QPS. Now almost a decade old and in the hands of a succession of commerce-impaired clueless corporations, it's still more usable, easier to administer, and more powerful than anything I've seen. Now if only *that* would get open sourced (a la PostGres) we'ld be getting somewhere.
Until then I'm placing my bets on well-customized SQL-compliant systems based on rigorous adherence to rich XML schemas.
Happy days,
Rustin
Data is the lever, rigor the fulcrum, brains the force that drives it all.
WebDAV really has nothing to do with the "Web" except that it uses the HTTP protocol. I would not consider that a "web-based" solution. In other words... WebDAV has nothing to do with a browser and everything to do with HTTP.
By comparison, all current Windows OSs have exclusive use for files, and it's widely used. So programs tend not to stomp on each other's files. This helps interoperability. Programs need only be compatible at the file level; they don't have to actively cooperate to maintain file integrity.
I'd like to see "always-on" exclusive use for Linux. If you ask for an open with exclusive use, you should be able to expect it to be available.