Re: [Phpwiki-talk] Wikilens ?

[Reini U. <ru...@x-...>]

Dan Frankowski schrieb:
> Arnaud Fontaine wrote:
> Thanks for your interest! First a note on WikiLens progress, then 
> description of integration with PhpWiki. The short story is: we are 
> progressing well on WikiLens; I'd like to merge with Phpwiki, but some 
> things make it hard for me; any help is appreciated.
> 
> *** WikiLens progress
> 
> "WindWhale" (1.3.9.GL4) was released in late Sept 2004. Its main 
> features were: stability and bugfixes; a login process that actually 
> worked. This is what is currently on the site (always available in full 
> source at http://www.wikilens.org/wikilens-src.tgz; see also 
> http://wikilens.org/wiki.php/WikiLens).
> 
> We have been furiously working on our next WikiLens release, 
> "MoonBadger" (1.3.9.GL5). I have tagged release candidate 1 (RC1), so it 
> should be released within a week. New features include:
> 
> - Ratemania (the ability to put ratings widgets anywhere, not 
> necessarily tied to pages)

we agree here.

> - Take most of the data we use out of page text (because our users were 
> accidentally deleting it and uncomfortable editing it), and put it in 
> meta-data with specialized editors. This includes category membership 
> and buddies.

This will cause problems, I believe. But users and developers should decide.
As long as it only affects the wikilens theme...
I bet jeff and steve will hate it, but I or carsten could be persuaded.

> - Better buddy support and visibility (easily add/delete buddies through 
> "manage buddies" or by adding buddies-of-buddies; buddies page ratings 
> show up at the top of every page; buddies who like an item show up in a 
> column on category page; etc.)

We agree here.
But I'd really like to be independent on manual buddy maintainence 
somewhen. There should be the possibility to extract the buddies 
automatically by clustering. Maybe offline. Implementation later somewhen.
But we'd need an externally accessible API. xmlrpc can get the pagetext, 
so simple reading will be ok. Storage could be another external sql 
table. Ss with the planned access log features (referrers, abuse, 
anti-spam).

> - More "list" support (show on every page any lists that page is on; 
> allow a user to add pages to a list either from the page, or from the 
> list editor each with an autocomplete textbox)

we'll probably agree here.

> - Improved pagelist look and feel (odd and even row highlighting, 
> spacing, no indenting, etc.).

we agree here.

> - Better category page sorting (case insensitive, bugfixing)
> 
> - A considerably faster ratings widget (all one piece with an image-map, 
> client-side rendered, instead of 11 separate pieces server-side 
> rendered), leading to a 6X reduction in category page size, and 
> noticeably faster page loading.

why not.

> - and more!
> 
> *** Merging with PhpWiki
> 
> Now, my thoughts on integration. First, I'd love for all of it to be 
> integrated into Phpwiki! This would give us wider distribution, and 
> Phpwiki more features and much-deserved credit. However, there are 
> several barriers for me:
> 
> 1. My plan is to only integrate with actual releases of PhpWiki, because 
> those presumably are especially stable points. We are based on 1.3.9. 
> 1.3.10 has well-known bugs that make us not wish to integrate. 1.3.11 
> has not been released for 9 months, and looks to still be adding 
> features (not the sign of a release). This makes me sad. I think 
> projects should 'release early and often.' Every 3 months, 4 at most. 
> Anyway, when it comes out, we will examine doing what I call a 
> "double-merge": first merging 1.3.11 into our stuff, then trying to 
> contribute back as much as we can. It has been so long (probably about a 
> year) that I fear this double merge will be hard, but I still want to 
> try it.

It will be not that hard for me as soon as the core settings are 
settled. The plugin, and pagelist API and theme-pref API is stable.
Template solution pending.

> 2. There are some small things that Reini has refused to accept. 
> Examples include: PageList::addColumnObject(), Smarty pre-processing of 
> page templates. My guess is MoonBadger may bring more such features. I 
> do not disapprove; this is his perogative, and he has to make the best 
> decisions for Phpwiki. However, each presents a small puzzle to me for 
> how to preserve our functioning system within those parameters.

I'm willing to discuss an alternate template system than the current 
phpwiki php subinvocation later, because that is our main remaining 
memory and time bottleneck as I found out in this year.
phpwiki-1.3.4 with a simple preg_replace template system was a LOT 
faster and needed almost no memory. (6MB for the hugest multi-requests, 
compared to ~32BM currently). A simple linux/apache is faster then 
windows for our current templates, but with proxy farms as on sf.net it 
is as slow as on windows.

Smarty is good for adding control logic to the templates, but we 
probably don't need loops (FOR/WHILE) in templates. Maybe IF.
But first I want to stabilize the existing stuff before thinking about a 
better template system.
Smarty need's a lot of memory and time for the save-step, but it better 
for reading thna our current templates.
Compared to our previous template system smarty is a huge overkill.
With the memory problems it will be impossible to save big pages on one 
step.
I'll try how to use simplier, faster templates though.
Dan, do you need FOR/WHILE, or just IF?

> 3. There are also some disagreements we have on project style. For 
> example, I believe Phpwiki should focus on very few back-ends. This 
> would allow more time to make those back-ends work really well, and to 
> do other features. I still see a lot of time dumped into Phpwiki 
> back-end maintenance, which seems like 'opportunity cost' and makes me 
> sad. WikiLens supports only the MySQL back-end.

That's a legacy burden we have to carry along. But it's not that hard, 
as long it is doable easily enough.
Also that's our niche. No other wiki has that much storage backends and 
platform support.

> Frankly, due to 1-3 above, the other developers on WikiLens have no 
> desire to merge with PhpWiki. They want to fork. Unfortunately, this 
> leaves me with less time and moral support to do the merging. When I 
> say, "Take a look at how Phpwiki current CVS does that" they roll their 
> eyes. Sometimes they look, sometimes not. When they don't look, our code 
> diverges more.
> 
> I think Reini is a lot faster at merging that I am. The last time he 
> estimated a day to merge WindWhale into Phpwiki. It would probably take 
> me at least a week, with my other work duties. MoonBadger (when it comes 
> out) will be even farther, hence take even longer.
> 
> Also, the last time Reini merged our code in, he both changed it and 
> broke it. Again, changing it is his perogative, but makes my developers 
> want to fork. Breaking it is of course unfortunate, and I'm sure he 
> didn't mean it, but costs us more time and makes the case for merging 
> harder.

Yes, I had to change the pagelist invocation for plugins, which is very 
very complicated. And I wanted to have most wikilens features at 
user-cfg'able and/or theme cfg'able options.

> What I am saying is I see all these factors pushing us towards forking, 
> even though I wish it weren't so. Things that would help us not fork:
> 
> - Frequent stable releases of Phpwiki. Once every 3 months, 4 at MOST. 
>   Many people want this, I think.

With 1.3.11 we had these huge and complicated php memory problems and 
pcre crashes with old markup. All these are finally settled.

Along the testing I also wanted to add some minor new features, because 
it is easier to test the whole system and cfg, if I ADD some 
un-important new stuff, than CHANGING existing stuff. The current 
problems are now just related with the changes in the existing core,
not with the new features.
Unfortunately php5 broke again, which is probably related to the 
workarounds for the pcre crashes.

> - Fewer disagreements about project and code style
> - A place where we could add our extensions without them being changed much

I try not to break it. But we have to agree on a common API for the 
complicated stuff. plugin, pagelist cols, prefs.
The pagelist col API for fancy features is quite complicated now.
We could improve that and document that better.

> Anyway, I eagerly wait the release of 1.3.11. Once we release 
> MoonBadger, I also would eagerly appreciate help in merging its features 
> into Phpwiki.

You got fancy release names now :)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/