Previously the WebDAV solution from C-Dot Consultants was only available on Apache web servers. Well, that's all changed!
The WebDAV suite from C-Dot Consultants was originally developed for the Apache2 web server. By abstracting out the protocol handling we have been able to port it to FCGI (Fast CGI), the premier portable scripting solution that is supported by most web servers - including Apache! We've tested the FCGI solution against Lighttpd, and while it hasn't been tested against any other FCGI-supporting web servers, the whole point of FCGI is that it should "just work"! As well as the FCGI support we've also interfaced to the HTTP::Daemon CPAN package, which means we now have an ultra-lightweight, stand alone, web-server-independent WebDAV solution.
We've also enhanced the plain files support in the server so that it can be used to access files on disk as well as Foswiki data.
In the course of all this work we have run the server against the latest release of the WebDAV standard Litmus tests, which highlighted a number of small protocol violations. We've fixed these and can now proudly report a 100% pass mark.Existing customers, please contact me if you haven't already received your package updates. New customers, you can get access to this software by contacting email@example.com
The thought is based on the interesting conclusion at the end of Michael's video: only humans invented the wheel and roads to use them on because they also invented taxes to build them collaboratively for mutual benefit. Animals don't have wheels because they did not invent roads … and taxes to fund them.Besides there is no evolutionary path towards a wheel, like half a wheel having half the benefit in transportation already. Giraffes have an evolutionary path towards longer and longer necks reaching more and more food. Wheels on the other hand are an artifact of invention, not evolution.
Then, if animals did spend time and resources to build roads, somebody else could use them as well, like their enemy, while breeding more instead of wasting resources on roads.However there's a point that gets lost here: if enough animals would build different stuff for mutual benefit, things start to level out again and everybody would gain more than the resources spent individually, which brings us to Open Source collaboration which let's us build stuff we couldn't on our own. Even animals from different species do coexist in symbiosis giving each other what the other one needs. And on a cellular level organisms consist of parts that only make sense in combination. In the end evolution did have enough time for animals to invent roads and wheels … and taxes.
Of course there are problematic cases in Open Source as well like there is in the world of animals with wheels. Some just use Open Source Software for their own benefit and don't give back on the same level. Yet still, so the pure Open Source doctrine, that doesn't hurt too much as the piece of work is used more widely thus increasing the impact and usefulness of the work on everyday's life. This in return increases the influential power of Open Source, and exactly that happened in recent years.
We just finished testing. I am really impressed how well the WebDAV interface respects all the permissions of the different Foswiki Webs. In our case, permissions are set in the Foswiki, but all users and groups are assigned in a Drupal system as rules (we use the DrupalUsersContrib User Manager for Foswiki). WebDAV directly accesses the Drupal MySQL database for user authentication. And it all just works perfectly fine.We will be using your WebDAV solution as secure fileserver, and treat the Wiki only as one way to access it (and to add descriptions to the different folders).
So nice to have a bit of positive feedback once in a while!If you want to purchase our extremely reasonably priced WebDAV solution for Foswiki, contact firstname.lastname@example.org
Here's a video that I still find particularly funny, even though it seems a bit outdated, not only because of its retro look&feel.
It's not what your wiki can do for you but what you can do for your wiki.The size of the blogospehere, that is the number of traditional blog sites out there, seems to be decreasing. At least that's what it feels to me. By no means am I able to come up with some real numbers of the size of the blogosphere. Yet still it is an ongoing process facing the rise of social platforms.
It might also be the case that blogs'n wikis are a known technology nobody talks about anymore, taking them for granted, not thrilling anybody anymore. Or is it simply too much of a hassle to come up with a well written story regularly? It is so much easier to crank out 140 chars of status updates.Another factor is mobile devices: nobody is enjoying typing into these cuties. Smartphones, the bulk of mobile devices, are bad for reading lengthy texts anyway. That's were tables come in: they make good reading devices, yet still no good content producing tools. Producing good content as a writer is quite a different task compared to reading the result as I recently commented on Karen McGrane's column about creating editing tools. Likewise mobile devices are good reading tools - more or less - while particularly bad supporting the authoring process by nature. And that's not only the case because we are lacking good content editors but for the fact that these devices have no keyboard, simple as it is.
At best, people type in a few lines of a status update or comment on somebody else's one. Seriously, nobody could be bothered typing more on mobile devices. So the rise of mobile internet also plays a factor in the fall of blogs as far as I can see. Or are there any good mobile blogging apps out there that people use regularly?Let's face it: the debate Blogs vs Wikis is no more. Both paradigms are facing a third one, the social platforms à la Facebook and friends. It is more a "Blogs and Wikis vs Facebook" debate (replace Facebook with your favorite social platform). It comes with a significantly different approach to sharing information being centered around people whereas blogs and wikis are centered around documents. That's the debate to follow: document vs user centric. The very same discussion is coined "old school vs new school knowledge management" on other occasions. In the end what's all the knowledge worth it without people using it. Each act of sharing knowledge on a blog, wiki of wherever is a social interaction with other people. Otherwise you could keep your thoughts for yourself. So putting people at the core of knowledge management instead of the documents that they share does make a lot of sense. As far as I see it, there is still a strong point in giving documents a structured place to live at, so people know they are "there". The central organization principle on social platforms - activity streams - feel too much in flux to be able to capture valuable knowledge long term. There are even cognitive limitations to consider when establishing a regime of activity streams. They have their strength, no doubt, as long as people show activities using it. All of the mentioned tools suffer from the adoption problem on the intranet facing low numbers of users and very homogeneous content types. Intranet is not big data you could mine for whatever purpose, it is all about metadata, mostly handcrafted.
Blogs are a very static activity stream if you want so, a linear order of articles. Wikis are more of a sack of things that don't have an aging factor. Blog postings as well as status message have this in common: they age and fade out in the past. Wikis don't age well, you have to review content and see if it is still relevant. But that's a very important process anyway to manage the quality of your content. No such thing is required on activity streams. They come and go automatically. People use it as an email replacement. When they have a question they ask again even though the very same question has been answered already somewhere down the stream. Retrieving it would take more time than asking again, a property that activity streams have in common with forums. Does anybody still use forums these days?
For a long time we've talked about stitching a relational database into Foswiki, mainly to speed up query searches. To keep things simple Foswiki uses a text database, which stores topics in lots of individual files. By default, searches are implemented by searching every one of these files individually for matching text. This isn't as bad as it sounds; searching is surprisingly fast. But it doesn't scale up terribly well, so people have coupled in various full-text search engines, such as Kinosearch, to accelerate text searches.
However there's been very little successful work yet on speeding up query searches - which is a shame, because query searches are heavily used in most wiki applications. The problem has always been that it's difficult to map from a Foswiki search query to any kind of structured search language, such as SQL.One approach (championed by WikiRing member Sven Dowideit) has been to support a wider range of queries in the text search engine. Using the code I wrote to map query searches to regular expressions, Sven has been able to couple Foswiki to the MongoDB database, with some pretty impressive results. This is already available as the MongoDBPlugin. Other approaches have tried to map Foswiki queries to other database search models, such as XQuery, but with little success. SQL is still the most common query language, and the RDBMS that support it are among some of the most mature and robust software on the planet. It's important that Foswiki has solutions that fall into that comfort zone. To that end I have implemented a new module, the DBIStoreContrib, that maps from the Foswiki query language to SQL. This allows us to use many of the existing RDBMS, such as MySQL, SQLite and PostgreSQL, to accelerate queries. By caching topics into the database in parallel to the text database, we avoid the risk of data loss that has made people nervous of other wiki solutions that use RDBMS, such as Mediawiki, while still maximising search performance.
It's early days for this module, and there's still lots to do to optimise how it works, so watch this space! If you are interested, and have a development environment, then you can check out the DBIStoreContrib from the Foswiki Subversion trunk.
Foswiki - the very best wiki application platform - is taking another giant leap forward….