Re: [podwiki] Re: Table syntax fix

[Thomas L. <to...@co...>]

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;