From: Adam S. <ad...@pe...> - 2001-09-18 18:28:25
|
> (Right now, the only page meta-data being used is 'locked' and > 'hits'.) This data is not visible (or editable) to the wiki-user > without providing some explicit mechanism for this. (I.e. the > MostPopular plugin displays the value of 'hits'.) (The DebugInfo > plugin currently displays all of the page meta-data --- but obviously > that would be fixed if sensitive information like passwords were > stored as page meta-data.) or maybe make debug only available to the listed wiki admins? also passwords should not be stored in plain text. what about a worse is better solution of just storing the crypted password as plainly visible metadata? it can be brute forced but it's simple and if people choose good passwords (ha!) it should be "good enough". > My thinking is that if everyone is going to have a WikiHomepage, then > storing their user information as part of the meta-data for their > homepage is a fine idea. i really like this idea, it feels like the "wiki way" to me. > How much user information do we envision storing, anyhow? > E-mail address > Password > Full name, probably maybe later, groups that you belong to (admin, editor etc) > Page change notification prefs: these might be better stored as > meta-data attached to the pages for which notification is desired? > Or one could also think up other schemes: user gets change > notifications for all pages linked from their homepage... i was just thinking about this. i think it makes more sense to have it stored in the page name, other wise every page update means that the entire user database has to be searched everytime a page is changed to see who should get emailed. however this means that unsubing from a wiki could be a pita if you have 10's of pages that you're sub'd to. some form of search tool or "unsub all" functionality would be very useful. > > For now we might just let the username link to a page of the same name, > > and if they want to be called HomePage, well, what can one do. > > But if it really is their homepage, they ought to be allowed to lock > it... lets not look at automated ways of stopping this. hopefully this will be a small enough problem that the admin can deal with it manually. most of the pages which would cause problems if someone chose them for a name (HomePage, FrontPage, RecentChanges, CategoryCategory etc) should exist by default in the basic wiki. > On the subject: I want to add the ability to generate word-level > diffs, a la emacs' ediff mode. This would be particularly useful for > wikis, where a "line" can be a whole paragraph --- if only one word > has been changed, often it's very hard to spot. I think this is a > fairly straightforward enhancement: compute the diff normally (by > lines), then foreach block of changed lines, split the blocks into > words and compute a diff by words. that would be great, can we have side by side diffs as well? adam. |