From: Jeff D. <da...@da...> - 2001-02-07 20:57:29
|
>> The move to PHP4: > >For a new development tree, which won't mature for at least six months, I >don't see the reason to slow down development by supporting the old 3.0.x... Okay, okay. You win. I agree that PHP4 is cool. Are there going to be bug fix releases of 1.2.x? Are the going to remain PHP3 compatible? Is that going to create headaches? >HTML == security hole, basically... we'd have to restrict the markup >allowed. The bar syntax allows any HTML. Sorry. By bar syntax, I meant (I saw this awhile ago on some other Wiki --- I can't remember which): || introduces a centered column |} introduces a right-justified column |{ introduces a left-justified column For example || Name || Number || Homepage || Jeff |} 123-4567 |{ http://x.y.z/ Your suggested markup (with the leading '@') is similar and fine, too. >Inevitiably people will want to use markup inside tables.. I will say it >again and keep saying it until I drive all of you off the project: We are >not going to reinvent HTML. It's not fun. I'm not sure I understand. Bold, italics, links and so forth inside tables should be allowable, and shouldn't preset a big problem. Tables within tables are excessive. >> Footnotes: >It's a small addition, already done, so it's a moot point... Yeah, I guess. I'm just thinking about redoing the database API's (for versions); and thinking that now would be a good time to get rid of carrying around all those page references (or footnotes). Remember that whenever the database API changes all six backends have to be fixed. Simpler is better. Maybe I don't completely understand the significance of footnotes. Why not just put the footnote in manually: Some text requiring a footnote [[1]. ... ---------- Footnotes: # A footnote. Or on a separate page? Some test requiring a footnote (See MoreDiscussionOfTheProblem.) Or Some test requiring a footnote [1|MoreDiscussionOfTheProblem]. >> Archiving Multiple Versions: >> >> This has been talked about forever. Back before I disappeared, >> I suggested a database API which handled this. You guys apparently >> didn't like it (that's okay). > >Oh no, I do like that idea. The wiki_pages table and the wiki_archive >table should have separate APIs. I think I disagree. >There's no reason to assume we will >always store pages in the archive the same way we store them in the >wiki_pages table. Agreed, but that's an implementation detail. The API should insulate us from that. >> Security: >Ack. That is bad. .htaccess? Or add 'nobody' to your group? Doesn't help (at least in my case). The .htaccess only affects access via HTTP. My group is 'users'. Personal groups are a good idea though, and I'll suggest it to the provider. >> PATH_INFO: >It fell off the radar. Ari has code for it, but we never integrated it. >You probably recall the NBTSC Wiki code is on Sourceforge in the ftp >directory. Yeah, I did it too, in the Jeff's hacks branch. I guess I should go look at that. >If there are no platform issues, I would rather see it a permanent >feature. I vaguely remember some issues regarding what happens when PHP is run from cgi-bin, rather than as an Apache plugin. Ari: do you remember anything about this? Jeff |