From: Rui C. <rui...@ac...> - 2003-01-24 23:56:28
|
Hello, Apologies for the long subject line. I tend to add summaries to everything these days. :) Also, apologies for the rather long(ish) message, which we can break down into separate threads as discussion (hopefully) progresses. First off, I've been fiddling with PhpWiki for a while now. After three months of not-very-subtle hacks, I now have a customized version up at http://mac.against.org that draws heavily from things like http://everything2.com and http://snipsnap.org. Some of the customization was done via plugins, and you can see a (very) brief description of the SeeAlso and DotGraph plugins here: http://mac.against.org/space/SeeAlso http://mac.against.org/space/DotGraph I've in fact been considering moving to SnipSnap - hence the URL structure I'm using - but have decided to stick around for a while and figure out where PhpWiki is heading and how I could contribute. I've also deployed a modified version of my personal Wiki inside my company, where it's being used for software/process modelling (hence DotGraph) and project documentation (hence SeeAlso). Initial feedback was very encouraging, but there were several interesting issues and requirements that I came across and that I would like to have the list's opinion on: 1) CamelCase is extremely confusing to some people. Square brackets are easy to grasp, however, which is interesting. Of special note was the fact that coding standards (thisIsAModuleName) sprung "?" all over the place when posting code fragments, but that is a separate issue. Yes, I know it's traditional. I've used Wikis for a while now, but only with techies. Case-insensitive bracketed links seem to work better (we're Portuguese, so cultural background must have some bearing on this that I've yet to grasp). 2) HTML (or simplified HTML) markup, with <code>/<pre> blocks exempt from parsing and "normal" headings, tables, etc. And not just for normal markup - RawHtml is extremely useful for inserting HTML form mock-ups inside the Wiki, enabling developers to quickly show to prospective users what the project will look like, etc., but is fiddly to use (oh, yes, normal users abhore plugin syntax...) 3) File attachments (and Wiki markup to refer to them) are of paramount importance. I'm considering storing them in the database (an attachment becoming a Wiki "node" in its own right) and using something along the lines of {inline: NodeName} to refer to them. I was wondering what work was being done along these lines, and I've seen some recent posts concerning this, but have yet to fetch the code and see how this was handled. Coding this would consist essentially of changing the database schema to hold the node mimetype alongside the content, doing some extra testing in getCurrentRevision(?) and suchlike and implementing a view.php URL handler. (A wanton hack like serialize()ing stuff into the current database schema seems to work, but I've yet to do more than a couple experiments.) 4) ACLs. Not just user login (I will probably have to integrate our Wiki with an LDAP directory, but Apache can sort that out for me), but the ability for any given user to lock a page to prevent users on the same privilege level from changing it. It can probably be a Unix-like Owner-Group-All field, but I'd like to know what people's opinions are on this. User management (which is implied) is done outside the box. 5) Comments. Not inline comments (Wiki editing), but distinct entries attached to a parent node. It comes right alongside ACLs as a base requirement. I've toured the alpha Wiki, and I've seen some interesting things there, but it feels like it should be an intrinsic thing - people are wary of editing other people's work and breaking something. 6) XML. Oooh. OK, this one is tricky, in the sense that yes, you can generate XML from Wiki markup (and I'm quite fond of the current XmlElement module, which seems well thought out), but the idea of actually storing XML instead of Wiki markup (and converting between the two whenever necessary) has sprung to mind. It makes a lot of sense, and would ensure the content is reusable if we have to re-render/import it/swap it with other systems. What do the developers think of this? 7) CVS - not as a backend, but as an integrated tool. CVStrac (http://cvs.cvstrac.org) has merged CVS, issue management and a (very usable) Wiki, and the idea is very appealing. Have there been any efforts along these lines? Issue management is also very interesting, but we have other tools for that. These were the recurring issues (and some of that can be seen in my http://mac.against.org/space/mac.2003-01-20 node...), and I'd love to know what other people think. Again, sorry for the long(ish) post, but scouring the mailing-list archives was not very useful in terms of understanding where PhpWiki stands where most of these issues are concerned, and the main PhpWiki has a rather sketchy feature roadmap. So I just had to ask. :) Best Regards, Rui Carmo |
From: Joby W. <joby@u.washington.edu> - 2003-01-25 00:30:59
|
Rui, We always welcome new developers. I'm pretty new myself... More comments inline: Rui Carmo wrote: > Some of the customization was done via plugins, and you can see a (very) > brief description of the SeeAlso and DotGraph plugins here: > > http://mac.against.org/space/SeeAlso Is this the changing gradient links at the bottom? > http://mac.against.org/space/DotGraph Very nice most definately welcome. > 1) CamelCase You can change the PCRE for WikiWords in index.php (currently there) to something impossible so that nothing matches. > 2) HTML (or simplified HTML) markup This has been a frequent request, but it is just a horrible idea. The point of the wiki syntax is to force standardization across the entire wiki, and it prevents a page from rendering broken. If you introduce HTML everywhere then you end up with some very broken wikis. > 3) File attachments (and Wiki markup to refer to them) Aren't uploads already in 1.3.4? Haven't paid much attention to that side... > 4) ACLs. We are already working on a Unix style User,Group,Other (rwx) Permissions http://phpwiki.sourceforge.net/phpwiki/PagePermissions > 5) Comments. Not inline comments (Wiki editing), but distinct entries > attached to a parent node. It comes right alongside ACLs as a base > requirement. I've toured the alpha Wiki, and I've seen some interesting > things there, but it feels like it should be an intrinsic thing - people > are wary of editing other people's work and breaking something. Not sure what you mean here. SubPages have been added... > 6) XML. Not a very good idea. If we store the WikiPages as XML, then we will have to convert from XML to WikiSyntax for an edit. Providing an XML data port should be sufficient. This can be looked at again (it has been mentioned many times), but IMHO there are higher priorities. > 7) CVS - not as a backend, but as an integrated tool. We do offer integrated diffs and versioning, which can be in a real db rather than the file structure (huge plus). So I am not sure of the advantage. > The main PhpWiki has a rather sketchy feature roadmap. Yeah... some organization would be nice, but my priorities: 1) New configuration system 2) User Authentication system 3) Group Authentication system 4) PagePermissions jbw |
From: Rui C. <rui...@ac...> - 2003-01-25 01:12:49
|
On Saturday, Jan 25, 2003, at 00:30 Europe/Lisbon, Joby Walker wrote: > Rui, > > We always welcome new developers. I'm pretty new myself... I can contribute my code (and layouts/theme/templates), as soon as I can remove the embarassing bits. :) > More comments inline: > > Rui Carmo wrote: >> Some of the customization was done via plugins, and you can see a >> (very) brief description of the SeeAlso and DotGraph plugins here: >> http://mac.against.org/space/SeeAlso > > Is this the changing gradient links at the bottom? Yep. Everything2 has them for a couple years now. That's SeeAlso, which is currently a patched BackLinks with some (slightly broken) filtering. Bit heavy (I've limited it to 20 links), might need to be cached. I've also modified the getPageLinks(?) functions to parse included pages and add them to the link list (that's the really heavy part). >> http://mac.against.org/space/DotGraph > > Very nice most definately welcome. Basically a VisualWiki that lets you write the GraphViz code inline. Has some problems with bad graphs (error messages don't print) and caching (caching is done in function of the plugin arguments, not an MD5 hash of anything between <?plugin <-> ?>, which is the proper way IMHO) >> 1) CamelCase > > You can change the PCRE for WikiWords in index.php (currently there) > to something impossible so that nothing matches. Yep, my point was more along the lines of contributing my users' feedback. I can't remember if I had to change anything to get the case-insensitive [link] matches, though (but then, it's getting late here). >> 2) HTML (or simplified HTML) markup > > This has been a frequent request, but it is just a horrible idea. The > point of the wiki syntax is to force standardization across the entire > wiki, and it prevents a page from rendering broken. If you introduce > HTML everywhere then you end up with some very broken wikis. Not if you parse/reparse it into XML. That would also allow for some preprocessing of IncludePages and similar plugins, leading to better performance ;) >> 3) File attachments (and Wiki markup to refer to them) > > Aren't uploads already in 1.3.4? Haven't paid much attention to that > side... Yeah, but just uploading files to a directory (which seems to be the basic functionality currently in CVS AFAIK) doesn't cut it... Too many issues regarding filenames, collisions, access levels, etc. >> 4) ACLs. > > We are already working on a Unix style User,Group,Other (rwx) > Permissions > > http://phpwiki.sourceforge.net/phpwiki/PagePermissions Yep. I was just wondering if it was in the code somewhere. I started off from 1.3.2 stable, and pecking through CVS wasn't very enlightenting as to what the current state of affairs might be. >> 5) Comments. Not inline comments (Wiki editing), but distinct entries >> attached to a parent node. It comes right alongside ACLs as a base >> requirement. I've toured the alpha Wiki, and I've seen some >> interesting things there, but it feels like it should be an intrinsic >> thing - people are wary of editing other people's work and breaking >> something. > > Not sure what you mean here. SubPages have been added... Hmmm... this (http://snipsnap.org/comments/SnipSnap-war) is pretty much it. note the simple layout and emphasis on the comment author's name. SubPages sort of works, but feels a bit odd (I have plenty of naive users to show these things to, and usability-wise, SubPages is tricky to grasp). I might have a go at hacking a nice layout into it. :) >> 6) XML. > > Not a very good idea. If we store the WikiPages as XML, then we will > have to convert from XML to WikiSyntax for an edit. Providing an XML > data port should be sufficient. This can be looked at again (it has > been mentioned many times), but IMHO there are higher priorities. Well, that's a matter of belief systems :) I don't see any issues with converting/reconverting, provided the converter is lenient enough. I've been mostly concerned with the parsing and the built-in PHP/XML functions, but nothing usable has come out (yet - we use XML and SOAP extensively, so it's just a matter of time). I'm also toying with the idea of using XML and XPath to build a fully XML-based Wiki (Cocoon springs to mind as a base), but I haven't had much time to investigate (nor does it make much sense with so many Wiki frameworks around). >> 7) CVS - not as a backend, but as an integrated tool. > > We do offer integrated diffs and versioning, which can be in a real db > rather than the file structure (huge plus). So I am not sure of the > advantage. No no no, not as versioning. :) A CVS backend to a Wiki is not to be underestimated, but that's not what I was getting at. Picture this: You have a RecentChanges-like page that tracks CVS commits. Commit comments can (easily) contain WikiLinks, hence providing direct links to Wiki nodes. Instant progress tracking ;) Check this out: http://cvs.cvstrac.org/timeline >> The main PhpWiki has a rather sketchy feature roadmap. > > Yeah... some organization would be nice, but my priorities: > > 1) New configuration system > 2) User Authentication system > 3) Group Authentication system > 4) PagePermissions > > jbw > Seems OK to me. But why Group Auth? PagePermissions would be the same issue, no? :) Is there any info on the database schema changes for those? R. |
From: Joby W. <joby@u.washington.edu> - 2003-01-30 22:51:07
|
Rui Carmo wrote: > On Saturday, Jan 25, 2003, at 00:30 Europe/Lisbon, Joby Walker wrote: >>> 4) ACLs. >> We are already working on a Unix style User,Group,Other (rwx) Permissions >> http://phpwiki.sourceforge.net/phpwiki/PagePermissions > Yep. I was just wondering if it was in the code somewhere. I started off > from 1.3.2 stable, and pecking through CVS wasn't very enlightenting as > to what the current state of affairs might be. Things have been delayed a bit. Reni is the point person on this project (with me as a second), but both of us have been very busy with other stuff for the past few months. I have just recently finished much of my part (at least initially). And hopefully we can get this part done soon. >>> 7) CVS - not as a backend, but as an integrated tool. > > Picture this: You have a RecentChanges-like page that tracks CVS > commits. Commit comments can (easily) contain WikiLinks, hence providing > direct links to Wiki nodes. Instant progress tracking ;) > > Check this out: http://cvs.cvstrac.org/timeline > Ahh... using the wiki to track a project in CVS! Interesting. I'd like to hear more. >>> The main PhpWiki has a rather sketchy feature roadmap. >> >> >> Yeah... some organization would be nice, but my priorities: >> >> 1) New configuration system >> 2) User Authentication system >> 3) Group Authentication system >> 4) PagePermissions >> >> jbw >> > > Seems OK to me. But why Group Auth? PagePermissions would be the same > issue, no? :) Correct they are part of the same project. > Is there any info on the database schema changes for those? Not necessarily. Our first priority is getting doing things the "WikiWay", so the primary user authentication system is based of meta-data on a page with the name of the user. Groups are similar: members are in a list on a page with the same name as the group, and a group is enabled by being list on a primary page. PagePermissions will also be meta-data. I am also trying to abstract things so DB, LDAP, XMLRPC, etc versions of elements can be written in the future without forcing a major code revision. jbw |
From: Rui C. <rui...@ac...> - 2003-01-31 00:19:44
|
Joby Walker wrote: > Rui Carmo wrote: > >> On Saturday, Jan 25, 2003, at 00:30 Europe/Lisbon, Joby Walker wrote: >>>> 4) ACLs. >> Yep. I was just wondering if it was in the code somewhere. I started >> off from 1.3.2 stable, and pecking through CVS wasn't very >> enlightenting as to what the current state of affairs might be. > > Things have been delayed a bit. Reni is the point person on this > project (with me as a second), but both of us have been very busy with > other stuff for the past few months. I have just recently finished much > of my part (at least initially). And hopefully we can get this part > done soon. > That's great to know. We've been drafting a set of "ideal" Wiki characteristics at http://mac.against.org/space/LiveWiki, and that's one of the main topics of discussion (that and authentication, since we need to integrate with internal systems). >>>> 7) CVS - not as a backend, but as an integrated tool. >> >> Picture this: You have a RecentChanges-like page that tracks CVS >> commits. Commit comments can (easily) contain WikiLinks, hence >> providing direct links to Wiki nodes. Instant progress tracking ;) >> >> Check this out: http://cvs.cvstrac.org/timeline >> > Ahh... using the wiki to track a project in CVS! Interesting. I'd like > to hear more. Well, the URL above points to a C-based tool that does exactly that. You can try it out right there (it's self-hosted). Wiki, trouble tickets and CVS are integrated into the same tool, and even though it is not quite TheWikiWay, you can set up an entire project site in no time flat. But back to PhpWiki. The way I see it, PhpWiki could be extended to do most of the usual project management tasks: - gathering requirements and change requests - managing documentation - assigning tasks - managing generic tasks/tickets/bugs (with history) - linking all the above to CVS operations (commits, forks, etc.) This would require some decidedly un-Wiki things like more structured task/ticket form layouts and some hooks into CVS, but it seems doable. (A facelift and a smart navigation bar tuned to project management would help, but that's a given when you customize PhpWiki) I'm using the Mantis bugtracker (http://mantisbt.sf.net, which is nice but with somewhat unstructured internals), and the real tricky thing to do on a Wiki would be good task reporting (and maybe a few Gantt charts - that Mantis needs too). >> Seems OK to me. But why Group Auth? PagePermissions would be the same >> issue, no? :) > > Correct they are part of the same project. > >> Is there any info on the database schema changes for those? > > Not necessarily. Our first priority is getting doing things the > "WikiWay", so the primary user authentication system is based of > meta-data on a page with the name of the user. Groups are similar: > members are in a list on a page with the same name as the group, and a > group is enabled by being list on a primary page. PagePermissions will > also be meta-data. Hmmm... I understand the need to pursue the WikiWay, but deploying a Wiki inside your typical company requires integrating it with an existing user/group model. I'll probably be patching our PhpWiki for Apache auth (letting Apache grab the credentials from an NT domain), and build a simple "drwxrwxrwx" - style access model. > I am also trying to abstract things so DB, LDAP, XMLRPC, etc versions of > elements can be written in the future without forcing a major code > revision. That would be great. The current DB support is great, but more abstraction would be nice on several levels. I'm particulary interested in content "per se", as in supporting multiple content types within the Wiki and translating them to other formats as needed. Anyone thinking along the lines of a content formatting pipeline? :) R. |
From: reini u. <ru...@x-...> - 2003-01-31 17:20:12
|
Joby Walker schrieb: > Rui Carmo wrote: >> On Saturday, Jan 25, 2003, at 00:30 Europe/Lisbon, Joby Walker wrote: >> >>>> 4) ACLs. >>> >>> We are already working on a Unix style User,Group,Other (rwx) >>> Permissions >>> http://phpwiki.sourceforge.net/phpwiki/PagePermissions >> >> Yep. I was just wondering if it was in the code somewhere. I started >> off from 1.3.2 stable, and pecking through CVS wasn't very >> enlightenting as to what the current state of affairs might be. > > > Things have been delayed a bit. Reni is the point person on this > project (with me as a second), but both of us have been very busy with > other stuff for the past few months. I have just recently finished much > of my part (at least initially). And hopefully we can get this part > done soon. I just started fixing this. I finished most of my office projects today. Thanks to Jochen Kalmbach for his usermanagement patches. This looks like to be what I needed. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Reini U. <ru...@x-...> - 2003-01-31 17:32:30
|
Rui Carmo schrieb: > That's great to know. We've been drafting a set of "ideal" Wiki > characteristics at http://mac.against.org/space/LiveWiki, and that's one > of the main topics of discussion (that and authentication, since we need > to integrate with internal systems). Rui, You write in your wanted feature set there: * "Page ACLs (drwxrwxrwx-like, with "d" being reserved for sysadmin override)" So you think that there should be pages, which shouldn't be accessed by root (the wikiadmin)? I wouldn't consider this a good idea, esp. when people can upload random attachments. * Could you elaborate on the "World Domination" button, please? GOD mode in DOOM would be Sign In as wikiadmin, or? * Markup permissions configurable. for example, guests can use "style markup" (b,i,u), editors can use links, powerusers can include <code> (eval anyone?) Good idea for group ACL attributes. |
From: Rui C. <rui...@ac...> - 2003-01-31 19:40:04
|
Reini Urban wrote: > Rui Carmo schrieb: > >> That's great to know. We've been drafting a set of "ideal" Wiki >> characteristics at http://mac.against.org/space/LiveWiki, and that's >> one of the main topics of discussion (that and authentication, since >> we need to integrate with internal systems). > > Rui, > You write in your wanted feature set there: > * "Page ACLs (drwxrwxrwx-like, with "d" being reserved for sysadmin > override)" > > So you think that there should be pages, which shouldn't be accessed by > root (the wikiadmin)? > I wouldn't consider this a good idea, esp. when people can upload random > attachments. No, that means the root user would be able to override permissions without destroying them. The first character would be used for a special flag (pretty much the same as when you do a mknod and list the results). A full user/capability ACL model would be better, but it's harder to implement and manage. > * Could you elaborate on the "World Domination" button, please? > > GOD mode in DOOM would be Sign In as wikiadmin, or? That was an inside joke aimed at Davi, the guy who added to the wish list. I'm OS-agnostic and he's a Debian-unstable addict, so we're constantly teasing each other. :) > * Markup permissions configurable. for example, guests can use "style > markup" (b,i,u), editors can use links, powerusers can include <code> > (eval anyone?) > > Good idea for group ACL attributes. Yes, and using an XML parser to render data helps a bit, since you can (for instance) use different XSLs according to the user level (blanking out or rendering links in different formats, for instance). The XML approach looks real promising at this point (but I'm not the one investigating it, so I can't go into any real detail). I'll be cleaning up SeeAlso and DotGraph this weekend, if time permits. Should I send them to anyone in particular when I'm finished? R. |
From: Kevin D. <ke...@do...> - 2003-01-31 20:57:44
|
On Friday 31 January 2003 7:38 pm, Rui Carmo wrote: > A full user/capability ACL model would be better, but it's harder to > implement and manage. Have you had a look at PHP Generic Access Control List (http://phpgacl.sourceforge.net), which seems to be a ready-made "drop-in" system? Of course, it may not be as easy to drop in as the author thinks .... Have a look anyway - it seems quite comprehensive. Kevin Donnelly |
From: Joby W. <joby@u.washington.edu> - 2003-01-31 21:09:50
|
Yeah, I've run across this project before. And it certainly has potential, but it doesn't support as many backends as we do. It only supports SQL DBs via ADODB, thus those using flatfiles or .db's would be left out. jbw Kevin Donnelly wrote: > On Friday 31 January 2003 7:38 pm, Rui Carmo wrote: > >>A full user/capability ACL model would be better, but it's harder to >>implement and manage. > > > Have you had a look at PHP Generic Access Control List > (http://phpgacl.sourceforge.net), which seems to be a ready-made "drop-in" > system? Of course, it may not be as easy to drop in as the author thinks > .... Have a look anyway - it seems quite comprehensive. > > Kevin Donnelly > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |