Re: [podwiki] Re: Table syntax fix
Brought to you by:
zarahg
From: Thomas L. <to...@co...> - 2004-05-13 09:29:57
|
On Wed, May 12, 2004 at 06:52:50AM -0500, David A. Bright wrote: > > last message you sent me. I believe you asked me to take a look at something > > else, besides the table fix, too, but can't remember what it was. Could you > > remind me? > > Now I remember, it was locking concurrent edits. I noticed you've done some > things with locking; is that still an issue? In fact, there are 2 issues: 1. as stated above: Edit Lock, that means If UserA starts editing a page, UserB should get a message ("edit in progress by UserA" or something). IMHO there are a couple of ways to do it, the best would be to do the lock itself using the underlying RCS. The only problem is, that such a look must have some timeout feature, say after 1 hour or so, if no change has been commited, the lock will be overridden (e.g. if another user tries to edit a locked page and if the lock is older than 1 hour, then override it (rcs -u)). But I'm not sure if I like this :-) Another way would be explicitly NOT to do locking but instead allow simultaneous edits and using rcsmerge to incorporate the changes of parallel edits into a new version. E.g: UserA opens Sandbox rev. 1.41 UserB opens Sandbox rev. 1.41 [ time goes by] UserA (the faster one) saves Sandbox to rev. 1.42 little bit later, UserB saves Sandbox. PodWiki now knows, that the revision is one (possibly more) version higher than the checked out one (for this to work, the current revision has to be stored via CGI var, of course). Now Sandbox rev. 1.42 and the Changes of UserB will be merged into rev. 1.43. The advantage of this: I don't have to deal with timeouts, dead pages (e.g. if the "unlock" does not work for some reason) and multiple users can really edit the same page (just like using CVS), which sounds cool for me. What do you think? 2. Locking at all. I'm having still problems under mod_perl with the DBM files (data/.pod*). Under fast-cgi the same problem exists, which a user told me some days ago. I already did some changes in save() to prevent simultaneous write's to the DBM files, but this seems still not to be enough. My current idea for a solution is somewhat more comprehensive: I think about completely going away from using DBM at all. When you google for DBM locking under mod_perl you will find a lot of questions, but not many solutions. For me, the (currently) best way would be to use plain text files. Here is my idea: I want to add another Module as a general wrapper for file access, which could be an OOP module. I would like to use my Config::General module for data storage/retrieval, because it creates user-editable files, so in the worst case, one could just correct errors directly in that files. Config::General is able to create any data structure, which can be used by Runner.pm via the mentioned OOP module, which itself holds those structures. This module can also cache the structures (under mod_perl and fast-cgi) to speed up read-access at least. For write's an explicit LOCK can be set directly on the target file(s). regards, Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |