podwiki-devel Mailing List for PodWiki (Page 2)
Brought to you by:
zarahg
Menu
▾
▴
podwiki-devel — PodWiki Development
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(31) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: David A. B. <Br...@ac...> - 2004-05-13 13:41:54
|
On Thu, 13 May 2004, Thomas Linden wrote:
> 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 :-)
I believe that TWiki does something very like this.
> Another way would be explicitly NOT to do locking but instead
> allow simultaneous edits and using rcsmerge to incorporate the
Hmmm, interesting idea.
> What do you think?
I'm not sure, but I tend toward the first alternative. You'd have to have a
pretty active wiki to really need the simultaneous edit feature.
> 2. Locking at all. I'm having still problems under mod_perl with
> My current idea for a solution is somewhat more comprehensive:
> I think about completely going away from using DBM at all. When
I like the idea of text files.
Got to get off to work...
--
David A. Bright
Br...@ac...
dab...@us...
|
|
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;
|
|
From: David A. B. <Br...@ac...> - 2004-05-12 11:50:22
|
On Wed, 12 May 2004, 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? -- David A. Bright Br...@ac... dab...@us... |
|
From: David A. B. <Br...@ac...> - 2004-05-12 11:45:03
|
Tom, I've checked in the fix you asked me to work on for tables. The =rowback directive is still accepted, but it is not required. You can now format a table like this: =table =row =cell Row 1 =cell R1, C2 =rowback =row =cell Row 2 =cell R2, C2 =row =cell Row 3 =cell R3, C3 =tableback Note that in row 1, I used the =rowback directive, just for illustrative purposes; it isn't required. The other rows show separation by just the =row directive. The change was mostly in Node.pm, where I changed the _make_rows function to be more like _make_cell, with successive rows siblings of each other, and cells are children of the rows. There was also a corresponding change in Runner.pm so that walk_row knew to go through the sibling nodes. Take a look when you have time and let me know what you think. By the way, I was a bit over-zealous in cleaning out old email the other day and deleted the 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? Thanks. -- David A. Bright Br...@ac... dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-05-05 10:42:47
|
On Tue, May 04, 2004 at 10:50:54PM -0500, David A. Bright wrote: > I do have a few other things I'd like to get done, though, so I'll keep my > hand in the code. If you are interested in my taking on anything specific > (e.g., TWiki formatter, something on your bug or TODO lists, something else?), > let me know. that would be great. Actually there is an issue to solve, which I didn't get right. The problem is in Pod/Tree/Node.pm (_make_cell() + _make_row() ). The tree iteration which catches the different cells for a row currently stops if =rowback or =tableback occurs. But I want it to stop also at =row, so that users can omit =rowback, e.g.: =table =row =cell blah =row =cell blubb =tableback these are 2 rows each containing one cell. I tried it out, but unsuccessfully. The problem seems, that if I stop on =row, this row will not start a new row iteration, which generates the following html (given the above example): <table> <tr> <td>blah</td> <--- </tr> missing here <tr> <td>blubb</td> </tr></tr> <--- here it is instead </table> I have really no idea how to solve this. If you could take a look at it :-) Another very required issue (from the TODO list) is Page Locking. If someone "opens" a page for editing it shall be readonly for others. In fact, I'm not sure how to implement such locking mechanism in a save and transparent way. To be honest, I did not take a look at other implementations, e.g. twiki. I really should, I know :-) kind 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; |
|
From: David A. B. <Br...@ac...> - 2004-05-05 04:48:43
|
I am now "finished" with the Tiki formatter, barring any new bug discoveries. I've added all the features that I need, and can reasonably implement, for my imported pages. At this point, I don't plan on adding any more features to this formatter. I do have a few other things I'd like to get done, though, so I'll keep my hand in the code. If you are interested in my taking on anything specific (e.g., TWiki formatter, something on your bug or TODO lists, something else?), let me know. I'm probably having too much fun with this... -- David A. Bright Br...@ac... dab...@us... |
|
From: David A. B. <Br...@ac...> - 2004-05-04 16:49:54
|
On Tue, 4 May 2004, Thomas Linden wrote: > I took a look at twiki (http://twiki.org) and surprisingly its > formatting looks very similar as my WikiShorthand formatter :-) Yes, I'm familiar with TWiki. I used to use it; I went from TWiki to UseMod to TikiWiki and now to PodWiki. I still like many of the things in TWiki; in fact, PodWiki reminds me of TWiki in some respects. > so, I'm thinking about adding a TwikiShorthand formatter, which can > be twiki compatible. Should be relatively easy. Go for it! > And, as I think of the possibilities, another thing comes to mind: > PodWiki could be used as a kind of "meta-wiki" tool, which understands > most markups. In the future there could be a convert function which > converts pages imported from another wiki to POD (or the default > Shorthand markup, see podwiki.conf). Ahhhh, yes. Since I have this history of several wikis, the external formatter concept of PodWiki was very attractive. I've gone through several conversions, none of which came out quite right, and I didn't want to convert again by hand; hence the Tiki formatter. It might be nice to have a conversion function. Although, I have to say that the POD format itself I find a little too "vertical" for my taste. The philosophy of TWiki I liked was that writing a wiki page was "as easy as writing an email." I probably won't ever write (large amounts) of POD wiki pages; I'll stick to the shorthand world. One of the things that I've thought might be nice is to have the formatters return text to Runner, rather than printing. Then, Runner is the only one that has to know how to break up the paragraphs, do the include processing, etc. So, it does become a meta-wiki tool in that respect. On another topic, you might want to take a look at the Changelog to see what I've been up to over the past 12 hours or so. The bugfix on included pages is actually pretty major; I was apalled that I hadn't caught that earlier. I must have only looked at POD format pages that did the includes. Let me know if my changes aren't clear. -- David A. Bright Br...@ac... dab...@us... |
|
From: David A. B. <Br...@ac...> - 2004-05-04 13:59:06
|
On Tue, 4 May 2004, Thomas Linden wrote: > finally I implemented tables for the POD markup too, it seems to work > as I expect. The question now is: shall we do this for the WikiShorthand > formatter too? I'm not sure. I think so. I've been pondering the issue for a while. I'm not particularly enamored of the tiki format, although it does have the advantage of having a definite table start/end mark (unlike the TWiki format, for example). It lacks the ability to specify attributes, such as header (<th>), alignment, etc. I used the TWiki format back when I was using that wiki. It was pretty easy to use. The thing that I particularly liked was that it pretty much did the "right thing" given a plain text representation of the table, so it was easy to take tables written in an email (I eschew HTML mail) and plunk them into a wiki page and they came out looking right. You could go the other way, too. So, I'm trying to think of a minimal-markup table syntax that still gives moderate layout control. I looked at your POD table layout and it looks promising. I'm curious though, it looks like "row" and "col" are reversed. From the Sandbox page: =table bgcolor=gree,border=1 =col =row blah =row blubber =colback =tableback produces (in wonderful ASCII art): +-------------+--------------+ | blah | blubber | +-------------+--------------+ when I would have expected: +-------------+ | blah | +-------------+ | blubber | +-------------+ I'll keep thinking about it. -- David A. Bright Br...@ac... dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-05-04 12:48:36
|
On Tue, May 04, 2004 at 01:49:21PM +0200, Thomas Linden wrote: > as I expect. The question now is: shall we do this for the WikiShorthand > formatter too? I'm not sure. I took a look at twiki (http://twiki.org) and surprisingly its formatting looks very similar as my WikiShorthand formatter :-) http://twiki.org/cgi-bin/view/TWiki/TextFormattingRules#TWikiShorthand so, I'm thinking about adding a TwikiShorthand formatter, which can be twiki compatible. And, as I think of the possibilities, another thing comes to mind: PodWiki could be used as a kind of "meta-wiki" tool, which understands most markups. In the future there could be a convert function which converts pages imported from another wiki to POD (or the default Shorthand markup, see podwiki.conf). 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; |
|
From: Thomas L. <to...@co...> - 2004-05-04 12:03:41
|
finally I implemented tables for the POD markup too, it seems to work as I expect. The question now is: shall we do this for the WikiShorthand formatter too? I'm not sure. Here is how it looks in POD: http://www.daemon.de/test/podwiki.pl?page=SandBox 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; |
|
From: David A. B. <Br...@ac...> - 2004-05-02 03:28:32
|
On Sat, 1 May 2004, Thomas Linden wrote: > So, I decided to separate them, and I made it. In addition I added a > standard disclaimer to each sourcefile. Looks good to me. > I am not sure about the copyright issue. The disclaimer itself always > refers to my Copyright on PodWiki in its own. If in some cases the > copyright differs from that, I added an "Additional copyright" section > telling that you have the copyright there, e.g. Formatter.pm or Tiki.pm. > Please review what I've done, I'm not sure if it's ok or correct. As they say, IANAL. It looks OK to me. -- David A. Bright Br...@ac... dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-05-01 18:05:01
|
Hi, I think it is ready for release 0.7.3, so if there are no objections I will made a release tarball and publish it these days. kind 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; |
|
From: Thomas L. <to...@co...> - 2004-05-01 10:59:19
|
On Fri, Apr 30, 2004 at 08:47:07AM -0500, David A. Bright wrote: > > finally I found a conflict. the pod_link() method which I changed > > recently, is in used differently, sometimes as method, sometimes as > > function: > > OK, I think I have this resolved now. It is always called as method. Now that > it is consistent, I don't have to have the funky local definitions in the > individual formatters that do the relay to SUPER::pod_link. ok, good :) > By the way, I wasn't sure whether to put all the "standard" formatters in the > Formatter.pm module or put them into separate modules in Podwiki/Formatter (as > is Tiki). Obviously, I ended up with them inside Formatter, but that does make > some things a little less consistent (like the registration code). Do you have > any opinions on that issue? I could pretty easily be swayed either direction. Yes, I thought about this too, I think it's better to have them separated. That way you can have separate cvs log entries and cvs revisions per module and that's what people (and developers) usually expect to look for a certain module (e.g. if someone finds an error in one of them). So, I decided to separate them, and I made it. In addition I added a standard disclaimer to each sourcefile. I am not sure about the copyright issue. The disclaimer itself always refers to my Copyright on PodWiki in its own. If in some cases the copyright differs from that, I added an "Additional copyright" section telling that you have the copyright there, e.g. Formatter.pm or Tiki.pm. Please review what I've done, I'm not sure if it's ok or correct. 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; |
|
From: David A. B. <Br...@ac...> - 2004-05-01 04:45:41
|
On Fri, 30 Apr 2004, Thomas Linden wrote: > finally I found a conflict. the pod_link() method which I changed > recently, is in used differently, sometimes as method, sometimes as > function: OK, I think I have this resolved now. It is always called as method. Now that it is consistent, I don't have to have the funky local definitions in the individual formatters that do the relay to SUPER::pod_link. By the way, I wasn't sure whether to put all the "standard" formatters in the Formatter.pm module or put them into separate modules in Podwiki/Formatter (as is Tiki). Obviously, I ended up with them inside Formatter, but that does make some things a little less consistent (like the registration code). Do you have any opinions on that issue? I could pretty easily be swayed either direction. -- David A. Bright Br...@ac... dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-04-29 22:32:34
|
finally I found a conflict. the pod_link() method which I changed
recently, is in used differently, sometimes as method, sometimes as
function:
Formatter.pm:389: s/\[([^\]]*)\]/&pod_link($1)/ge;
Formatter.pm:458: $this->SUPER::pod_link($link_text);
Formatter/Tiki.pm:144: s/\(\(($page_regex)\|([^\)]+)\)\)/$this->pod_link($2 . "|" . $1)/ge;
Formatter/Tiki.pm:296: $this->SUPER::pod_link($link_text);
we should decide for one way and go with it :-)
I suggest you fix this, 'cause you seem still working on it. I have to
go out with my dog and then to bed (it's 00:23 here).
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;
|
|
From: Thomas L. <to...@co...> - 2004-04-29 20:24:12
|
i -- 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; |
