You described the situation almost exactly, including that the database explanation, at least so far, has been ignored.  The only difference is while the majority of engineers approved it after the demo, the managers in charge did not.  I’m almost out of gas on this one, it’s been months, and the outcome was unexpected.


From: Neill Mitchell []
Sent: Friday, January 27, 2012 12:45 PM
Subject: Re: [SMW-devel] Big problem with SMW/MW versus Foswiki



In a word - MySQL. How would SMW's query engine work with foswiki's flat file "database"? You need a database engine capable of handling SQL queries. You would think that was evidence enough, but unfortunately you are dealing with non technical people, so you are wasting your time presenting technical reasons.

I had exactly this at the last company I worked for. As you are dealing with non technical people, the best way is to play politics with politics. You'll never beat them with technical argument. A practical demonstration is called for. Show the key decision maker all the information in your SMW instance and how easy it is to write a query to leverage that information and display it in a meaningful way. Then show them the foswiki which will have none of that functionality.

You need to demonstrate the usefulness of the information in your SMW wiki and how it benefits the business and how the efficiency of the business will be compromised if the information is effectively lost. This worked for me and the largest handset manufacturer in the world switched from twiki to Mediawiki :)

Good luck!

On 27/01/12 17:37, Sal Quintanilla wrote:

Hi Folks,


I’ve created a pretty amazing SMW intranet installation for our engineering department.  Without spending too much time describing it, at the high level it


-          Promotes reusability though automatic cross-referencing and advertising of content

-          Uses forms and templates to support symmetric looking page types (like project pages, technical articles, status reports, user profile pages) while still including free text for customization of information

-          Includes parametric search based on several families of tags that are attached to almost everything


It’s been evolving and running for over a year, has a few thousand meaningful articles, and has been well-received by our engineering community.


We also have a foswiki installation.  It started as twiki more than 7 years ago and was migrated to foswiki about a year ago.  The foswiki install is on an IT-managed server and is the official corporate wiki. 


In an effort to streamline operations, the decision has been made to scrap our SMW server.  For the most part, the decision makers used the point that SMW is a wiki, foswiki is a wiki, foswiki is already adopted, we’ll use foswiki.  The infrastructure I added was essentially deemed insignificant in the arguments (non-engineers made this assessment, I couldn’t convince them otherwise after a year of trying, nor could other engineers).  However, they did say that my designs could be handed to our foswiki team and adapted to it. 


I’m writing to the developer list to ask for insights into why foswiki can or cannot support such a system.  I know it supports forms and templates, but I have my doubts about the rich query support I’m doing, given that foswiki uses text files for storage and its own core for access, while Mediawiki uses a database and lets the mysql process do a lot of work for it.  What I don’t have is real evidence.  Does anyone have any empirical or other statements for why such a transfer can’t take place? 


Thanks guys.


Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!

Semediawiki-devel mailing list