On Apr 2, 2009, at 8:46 AM, Mihai Danila wrote:
Oops... I've been banned for a week, so I couldn't reply. Let me put my perspective on this issue out there and you can tell me what you think.Wikis are used pervasively in company intranets. They help developer teams share fast changing information while at the same time providing document linking, a key ingredient of the hypertext technology. That's what Cunningham's Wiki was, and I believe still is about, and I'm sure everyone is on board so far. Wikis also maintain document history; not sure if the C2 wiki supports it, but that's the idea.In a step away from Cunningham's wiki, which is purely text based, the various Wiki implementations starting adding multimedia support, for the most part through the inclusion of images in a web page. Then of course file attachments came as a natural addition, because why not let the vehicle that supported image uploads support any kind of uploads. Said, done, and it works well.Now comes the rift that I've been attacking in this thread, the incomplete version support. So-called purists who indicate that the Wiki is primarily a text presentation platform are mistaken, since, as I indicated, the Wiki has already moved beyond the point of being a text presentation platform. In fact, from a purist standpoint, versioning should support all media across the board; not only that, versioning should address the logical unit of presentation, the web page. And since the web page is a multimedia document, made of text and images, it makes sense for history to save image history along with text history.The size of the resulting website is another argument against supporting versioning across the board which is not pertinent in the company intranet scenario. And hey, who is to say that you need to use versioning on your disk space limited public website? I never suggested that media versioning needs to be forced upon users. Furthermore, that media do not change often and can be addressed by backups is actually hard to grasp as a valid argument. I want a reliable tool, if at all possible, and a setup where I rely on weekly backups to keep my history is NOT reliable. So if the tool can be made reliable, why suggest going with the less reliable option on the account that "media do not change often"?At the end of the day, it seems that all the arguments I have heard against the suggested feature really boil down to "I don't need it, so don't implement it."What do you think? Mihai Danila On Mar 25, 2009, at 6:03 AM, Dmitry Katsubo wrote:Well, to tell you the truth: Old versions just aren't saved. Thereexists a feature request for this in the bugtracker since some time, butafaik nobody has yet been working on it. I've added that media logbefore the release, but it is nothing more than a log and most useful for clients using the XML-RPC interface to fetch media data and who want to know if anything and if yes which files have changed (and need to berefreshed).Hi Michael! I completely agree with you: for wiki there is no need to store allversions of media files. It consumes space, as they do not change often,one can organize incremental backup of wiki data and restore it later from backup.But as you have a log... why not to display it? Just have an opportunityto see all actions on a given resource as a list/table ([Added|Removed|Replaced] by [User] on [Date])? Only the log, no "rollback to previous version" facility. Thanks! -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist
I'm wondering if the e-mail ever reached you. Internal procedure within my company is still on hold, pending resolution of this request. Thanks.
-- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist
