Re: [Phpwiki-talk] Updates with WikiLens code ?

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

Dan Frankowski schrieb:
> I'd send you this personally, but you like me to email phpwiki-talk, so 
> here goes.
> 
> WikiLens has been drifting farther and farther from PhpWiki code. 
> However, I'd love to contribute the code back into PhpWiki! There are 
> several issues, tho. I'd appreciate your advice.

Before reading it, I think that adding smarty dependency is way we 
cannot follow.

> 1. I'd be happy to apply changes myself, and I have the SourceForge 
> permissions, but I don't want to make changes you don't approve of. This 
> leaves me in the position of trying to get approval, so I am less 
> inclined to change the code. Would it make sense if we just went ahead 
> and started making changes, and allowed you to reverse what you thought 
> was very bad?

everything besides the required smarty dependency. you can make it 
optional though for several features you need (user-editable templates).

> 2. My plan was to take 1.3.11, integrate its changes into WikiLens code, 
> then take the merged stuff from our codebase and submit it back. 
> However, 1.3.11 has been delayed for a LONG time. I am unwilling to 
> integrate in-between releases because I fear the code might be unstable, 
> so we are in a holding pattern.

well, I still cannot reproduce the sf.net problem, exhausting memory on 
large pagelists. I build several debugging php versions to no avail.
So I think the solution is to recommend a new php (4.3x works fine) for 
phpwiki > 400 pages and a sql database. 4.2 and earlier is not recommended.

And I try to improve the postgres interface, because mysql is very bad 
in terms of locking. we should really get rid of the sf.net webservices 
or fall back to dba there.

> 3. We are sorely tempted to add a database table every now and then. For 
> example, we are considering putting category links in their own table 
> instead of making them page links, to try to solve 2 issues: a) 
> unintentional category membership (by refering to a page, but not 
> wanting it to be a category reference, with all that means); b) naive 
> users deleting the category membership.

non user-not editable category membership could also go to meta-data, 
but this cannot be searched efficiently. The main problem is WikiDB 
transparency. we have to think that dba should stay the default.

> We've fixed bugs (from our point of view) in PhpWiki. I submitted some 
> patches (e.g., 994497), but it is extra effort to do so. Therefore, 
> we've fixed bugs I haven't submitted patches for.

ah, I didn't see them. I'll have a look. I just study your wikilens 
sources from time to time.

> We've added features. For example, we have a CreatePage plugin that 
> allows you to import Amazon books with structured information, we have a 
> new login process that we feel is smoother. I bet we have lots of other 
> features as well that I've forgotten to detail.

yes, I saw.
I prefer your login process and the better layout.
With CreatePage we have to merge with my version, because I added some 
new features also. I do it with my private imdb library, getting missing 
params from the imdb database. you do it by quering amazon.
this sounds very similar.

FYI:
I'll go into this direction during the next year. My paid job with phpwiki:

Improve interface to display complex relationships and improve graphical 
analysis. WikiFormRich, PloticusSql. See the ploticus samples and quisp.
   http://aretha.jax.org/pub-cgi/phenome/mpdcgi?rtn=datamodel/datamodel
instead of quisp, some graph generation tool (ploticus most likely) will 
be used to display pagelist results and external sql queries.
excel-like graphs to display them. PhpWiki as some kind a excel frontend 
with revisions and permissions.

Your StructuredData approach also looks very, very good to edit it.

I'll probably also have use an external AI expert system (lisa, clips, 
...) with user-editable rules (models) in wikipages, to define objects, 
relationship and distance. I'm just setting this up.

WikiPluginCached needs to be improved, because this is a nightmare to 
configure and use.
Maybe we should get rid of the pear Cache lib at all and use the md5'ify 
all args trick and use this as cached filename. Like the TeX2png plugin 
by Pierrick. This is much simplier and faster. It only has to be 
extended to handle html/map/png files also.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/