Re: [Phpwiki-talk] wikinames, layout, db, and more

[Steve W. <sw...@wc...>]

On Tue, 6 Jun 2000, Nicholas Roberts wrote:

> I assume that we are not bound by
> > backwards-compatibility?
> 
> will we have to re-enter our pages manually? could we make a sript that
> migrates our data into the new schema?

Only if you launched on the old MySQL code base, and even then it would be
possible to write a conversion script. I don't see any backwards
compatibility issues with the DBM storage approach. (What are you using on
NT, by the way?)

> > If we need some kind of authentication I would suggest that we
> > basically just have two users: anonymous and admin. This allows
> > e.g. to have "frozen" pages which only admin people can edit or unfreeze.
> > (Might be useful for system documentation or other sensitive stuff.)
> 
> I envision 3 states for a page
> 
> 1. Frozen: only admin can alter
> 2. Comment-On: main text frozen for anonymous (admin full access), time and
> author-stamped comments allowable at the bottom of the page
> 3. Open: free-form classic wiki editing

This will be the easy part... creating the user auth system and
integrating it will be the hard part. Security always makes things more
difficult.

> 
> 
> References & Footnotes
> 
> I think that is is useful to have these. I would like to see Footnotes &
> References to be more structured. I think it makes great sense to have each
> Reference unique, so they can be re-used, maybe something like
> PhpWikii:NSTBCWiki:WelcomeVistors:1.
> 
> Maybe if you wanted to use it in another page it could be [r |
> WelcomeVistors.1]
> 
> The other alternative (the way EditThisPage handles it) is to have site-wide
> references, thereby guarneteeing uniqueness
> 
> 
> ie
> Editing Form
> Number/shortcut [1]
> URL [http:/some.url.com]
> Title [This URL is about PHPWiki] - optional
> Author [Swain & Hollosi]  - optional
> 
> if a template was used it would be easy to turn-off/on and re-position
> footnotes, perhaps making them a seperate page, or allwing them to be
> expanded into the page etc?
> 

Yes, and this could be related to another idea I've had about storing page
names in a persistent data structure; does PHP support global variables
the way mod_perl does? If it did we could maintain a list of defined and
undefined pages, though at the moment my head is congested and I can't
remember why I wanted to do this :-)

All in all, we'll probably wind up doing the simplest/most important
things first. I don't see references changing much in the near future.

> 
> Images
> 
> I am a big fan of images/photos/visual metaphors, so I'd like to see a more
> elegant image system
> 

In my experience with Wikis, images are rarely utilized; beyond making
them easier to embed I think it would be time wasted to do any more.

In particular, we have to be careful of trying to reinvent HTML. Before
long people will be asking for tables and frames and Javascript, and
that's when I go into retirement :-)

> Editing Form
> Name/shortcut [Fern]
> Source URL [http://some.url.com/images/fern.gif ]
> Hyperlink [http://some.url.com/fern.html]
> Alt [This photo is a fern] - optional
> Author [Swain & Hollosi]  - optional
> 
> then maybe everytime an author writes [i | fern] the Fern image is embedded.
> Perhaps again it would be good to have site-wide image registration.
> 

I think these are both good ideas. They shouldn't be hard to implement,
but they hinge on the new database schemas and whatever performance
impact. i.e. let's wait and see when we have the new DB interface worked
out.

> 
> It seems that we are getting away from the original classic Wiki, but I
> noticed TheTcler Wiki has a lot of great enchancements. I am using PhpWiki
> for a Uni project and so will be doing a lot of work along these lines
> anyway and it would be great if they where integrated in the 'official'
> PhpWiki, even if they are options to be activated.

I am leaving the 1.03 release as is, which is very very close to the
original Wiki. (Change the logo and you probably could fool Ward
Cunningham ;-) 

My desire is to push this architecture in new and interesting ways, and
eventually when the 1.2 series matures, write a new one from scratch,
because it will probably reach a point where we will have to anyway.


> 
> I am looking at getting PhpWiki to work with the following;
> 
> PhpHoo2
> PHPSlash (with PHPLib for support)
> TWIG
> Listman
> Webmin
> 
> At first I am going for a SyncreticHack, then after a few iterations I might
> get somekind of SourceForge style seemlessness
> 
> see http://synarchy.net/usyd/ped/task0.html


Ah, to be in college again :-)

I'm also interested in a Slashdot front end to PhpWiki, and right now my
thinking is that it will be a seperate file, a.k.a. wiki_weblog.php3
(which can optionally be made index.php3).

After reading through this and looking at your drawings I understand why
you want a more component-based approach... your drawings remind me an
awful lot of Ted Neson's :-)

sw

...............................ooo0000ooo..................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain