From: Steve W. <sw...@wc...> - 2000-07-02 22:25:52
|
I have the PhpWiki+MySQL installation on SF working (http://phpwiki.sourceforge.net/phpwiki/). This is going to be the main PhpWiki site soon. I am going to write conversion routines to: * port from one DB to another (in this case it will be DBM -> MySQL but it will work AnyDB -> AnyDB) * port version 1.0 Wikis to 1.[12] Wikis. This might be the beginning of 'auth' capabilities. That is, DB porting is something the admin should only have access to, so I want to create a general design soon for admin features (it will also include: exporting pages as HTML, locking pages, and "rebuilding" DBM files.) I am particulary keen on getting page locking done, because I am tired of clearing out graffiti like http://phpwiki.sourceforge.net:80/wiki/index.php3?SteveWainsteadEatsWormsAndBlowsGoats. I mean, my personal life is nobody's business ;-) sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: J C L. <cl...@ka...> - 2000-07-03 05:19:50
|
On Sun, 2 Jul 2000 18:21:11 -0400 (EDT) Steve Wainstead <sw...@wc...> wrote: > I am particulary keen on getting page locking done, because I am > tired of clearing out graffiti like > http://phpwiki.sourceforge.net:80/wiki/index.php3?SteveWainsteadEatsWormsAndBlowsGoats. > I mean, my personal life is nobody's business ;-) I have some plans for a Wiki and was intending to worj off a base of PHPWiki: -- PHPLib based authentication. -- Moving DB access under PHPLib -- Editing and page creation only by people with accounts. -- Concept if "groups of users" ala Unix groups -- Concept of a page "belonging" to a user. -- Concept of that user granting edit rights to a named group. -- Ability for a user to transfer ownership (and therefore rights) of a page from himself to another user. -- Ability to show an index of all the Wiki pages belonging to a particular user or group ("Owner Indexes"). -- Page histories with prior versions view available (encluding ownership changes). -- Inter-version colourised diff-style views available of edited pages -- Ability for a Wiki page to be attached/associated with another Wiki Page in the manner of a comment on the parent Wiki page. Such Wiki Comment Pages, as they are not stand-alone pages in their own right would be auto-named ala <UserID>.<Some_#> or such. -- Ability for such "comments" to be threaded and the entire thread tree to be displayed on a single page with indent-stlye threading. -- Ability for a Wiki page to be "attached" to a non-Wiki page (eg local site URL). Also, by extention, for Wiki threads to be so rooted on URLs. -- Ability for a Wiki page to reference (special tag format) other Wiki pages or Wiki Comments in a page such that the contents of the referenced page are displayed in-line (perhaps via TreeDoc (http://www.softky.com/TreeDoc/)). ("In-place Wiki") -- Ability to link from a Wiki link in an In-place Wiki or Owner Index to the original context of that Wiki Page/Cpomment (eg the original comment-thread) -- Careful use of indexes and Meta-robots such that such Wiki networks are correctly search engine indexable. I'd like to work with, or at least not against, the PHPWiki team in this. Does any of the above directly conflict with the PHPWiki team's plans for PHPWiki? -- "Show me the way to go home" Home: cl...@ka... J C Lawrence Other: co...@ka... ----------(*) Keys etc: finger cl...@ka... --=| A man is as sane as he is dangerous to his environment |=-- |
From: Arno H. <aho...@in...> - 2000-07-03 21:35:13
|
Hi J C, here are my two cents: > -- PHPLib based authentication. > -- Moving DB access under PHPLib I'm not too keen on using PHPLib. Authentication is easy to do oneself and the DB layer doesn't take dbm into account. Also, with advanced stuff to come, it might even be that the SQL itself has to be different. > -- Editing and page creation only by people with accounts. > -- Concept if "groups of users" ala Unix groups > -- Concept of a page "belonging" to a user. > -- Concept of that user granting edit rights to a named group. > -- Ability for a user to transfer ownership (and therefore rights) > of a page from himself to another user. > -- Ability to show an index of all the Wiki pages belonging to a > particular user or group ("Owner Indexes"). These go all hand in hand. Although interesting, full support for accounts is not a major issue for 1.2. Maybe for later releases. I think the next big thing will be modularizing phpwiki. When this is done, it should be easy to add accounts without too much hassle. > -- Page histories with prior versions view available (encluding > ownership changes). We already have a diff in 1.1.6 - only the prior version though. I assume that eventually this will develop into a full versioning system. > -- Inter-version colourised diff-style views available of edited pages Nice gimmick. Maybe Jeff is willing to implement this. > -- Ability for a Wiki page to be attached/associated with another > Wiki Page in the manner of a comment on the parent Wiki page. > Such Wiki Comment Pages, as they are not stand-alone pages in > their own right would be auto-named ala <UserID>.<Some_#> or such. > -- Ability for such "comments" to be threaded and the entire > thread tree to be displayed on a single page with indent-stlye > threading. I don't see how this could be useful. Could you give an example? If I want to have threaded discussions I'd use something like phorum. > -- Ability for a Wiki page to be "attached" to a non-Wiki page (eg > local site URL). Also, by extention, for Wiki threads to be so > rooted on URLs. This can already be done. wiki_transform.php3 places all its output into a variable, which can be processed further. The attaching functionality has to be implemented by the non-Wiki page. > -- Ability for a Wiki page to reference (special tag format) other > Wiki pages or Wiki Comments in a page such that the contents of > the referenced page are displayed in-line (perhaps via TreeDoc > (http://www.softky.com/TreeDoc/)). ("In-place Wiki") Again, could you give an example why this is useful? > -- Careful use of indexes and Meta-robots such that such Wiki > networks are correctly search engine indexable. We are working on that. What are meta-robots (or do you mean simple web-bots indexing web pages?) Maybe you should read about WikiEssence, WikiNature, etc. on c2.com. IMHO, if you overload wiki with functionality it ceases to be a wiki. But then, maybe that's your aim, i.e. creating something different based on a wiki. Especially, if you change the way topics are discussed within a wiki, the whole thing will take on a totally different nature. Note: I'm not saying that discussion within wiki is perfect. But it contributes to that wiki feeling that is part of wiki's attraction. /Arno |
From: J C L. <cl...@ka...> - 2000-07-03 22:50:51
|
On Mon, 3 Jul 2000 23:34:23 +0200 (MEST) Arno Hollosi <aho...@in...> wrote: >> -- PHPLib based authentication. -- Moving DB access under PHPLib > I'm not too keen on using PHPLib. I need to integrate into an envionment which is PHPLib based. > Authentication is easy to do oneself and the DB layer doesn't take > dbm into account. <nod> I've noticed that I very rarely ever do pages any more that don't involve an SQL backend somehow. > Also, with advanced stuff to come, it might even be that the SQL > itself has to be different. Easy to abstract and change. There's been discussion of this lately on the PHPLib list in regard to moving from MySQL to Oracle (which I'll probably be doing eventually) and how to make that transition easy with the various SQL differences. >> -- Editing and page creation only by people with accounts. -- >> Concept if "groups of users" ala Unix groups -- Concept of a page >> "belonging" to a user. -- Concept of that user granting edit >> rights to a named group. -- Ability for a user to transfer >> ownership (and therefore rights) of a page from himself to >> another user. -- Ability to show an index of all the Wiki pages >> belonging to a particular user or group ("Owner Indexes"). > These go all hand in hand. Although interesting, full support for > accounts is not a major issue for 1.2. Maybe for later releases. > I think the next big thing will be modularizing phpwiki. When this > is done, it should be easy to add accounts without too much > hassle. Perhaps I should restate my original post. What I listed are some of the things I'll be doing. I'm starting from a base of PHPWiki. I'd like to not work against the PHPWiki developers in doing this, but it is what I'm doing with a timetable on the order of a few months. >> -- Ability for a Wiki page to be attached/associated with another >> Wiki Page in the manner of a comment on the parent Wiki page. >> Such Wiki Comment Pages, as they are not stand-alone pages in >> their own right would be auto-named ala <UserID>.<Some_#> or >> such. -- Ability for such "comments" to be threaded and the >> entire thread tree to be displayed on a single page with >> indent-stlye threading. > I don't see how this could be useful. Could you give an example? Part of the intent is to use a Wiki as a) a corporate documentation and research system, and b) as a meta-level evaluation system which runs in parallel with a pre-established Wiki or non-Wiki site. cf: http://crit.org/ > If I want to have threaded discussions I'd use something like > phorum. Think of phorum constructed entirely of WikiItems. Now think of that both as the main site along with various other static pages, and as a parallel meta layer commenting, evaluating, and referencing the main site. That's what I'm doing. >> -- Ability for a Wiki page to be "attached" to a non-Wiki page >> (eg local site URL). Also, by extention, for Wiki threads to be >> so rooted on URLs. > This can already be done. wiki_transform.php3 places all its > output into a variable, which can be processed further. The > attaching functionality has to be implemented by the non-Wiki > page. <nod> I'd like something a little more elegant (piping thru PHPLib templates among other things), but yes. >> -- Ability for a Wiki page to reference (special tag format) >> other Wiki pages or Wiki Comments in a page such that the >> contents of the referenced page are displayed in-line (perhaps >> via TreeDoc (http://www.softky.com/TreeDoc/)). ("In-place Wiki") > Again, could you give an example why this is useful? Consider a researcher mining a Wiki farm and constructing a Wiki document of notes on what he found and evaluated, in-place quoting the other WikiItems he referenced. >> -- Careful use of indexes and Meta-robots such that such Wiki >> networks are correctly search engine indexable. > We are working on that. What are meta-robots (or do you mean > simple web-bots indexing web pages?) The Meta robots entry ala: <meta name="robots" content="index,follow"> Given that in the system I describe the content of a given WikiItem may simultaneously appear in multiple contexts (as a stand-alone item, as part of a threaded WikiDiscussion, abstracted as a quoted WikiItem into another WikiPage, etc) providing suitable clues for external search engines to make searching as useful as possible takes a little thought. I need Google and AltaVista to be able to usefully index the resulting WikiWeb (you don't want 20 matches to the same item in different contexts). > Maybe you should read about WikiEssence, WikiNature, etc. on > c2.com. Yes, I'm familiar with those documents and with Wikis in general. I realise that what I'm creating is not really a classical Wiki, and in many ways deliberately sunders the basic design models and assumptions of classical Wiki. This is intentional. > IMHO, if you overload wiki with functionality it ceases to be a > wiki. Yup. If I wanted a straight Wiki I'd be using any of the several dozen already out there rather than building something new. > But then, maybe that's your aim, i.e. creating something different > based on a wiki. Exactly. My intent is to extend the benefits of Wiki on an architectural scale to entire web sites. > Especially, if you change the way topics are discussed within a > wiki, the whole thing will take on a totally different nature. Bingo. Wiki has been done. > Note: I'm not saying that discussion within wiki is perfect. But > it contributes to that wiki feeling that is part of wiki's > attraction. Agreed. When viewed a particular way what I'm really doing is adding the ability for the author of a WikiItem to define an explicit for his WikiItem (as versus being a purely abstracted node), and for others to then explicitly place that WikiItem and others in new contexts without invalidating or altering the original context, and to then allow those contexts to be manipulated as definitions in their own rights. -- "Finally coming home" Home: cl...@ka... J C Lawrence Other: co...@ka... ----------(*) Keys etc: finger cl...@ka... --=| A man is as sane as he is dangerous to his environment |=-- |
From: J C L. <cl...@ka...> - 2000-07-03 23:05:35
|
<<Sorry, I accidentally screwed the addressing ont he first copy>> On Mon, 03 Jul 2000 15:46:00 -0700 J C Lawrence <cl...@ka...> wrote: > Agreed. When viewed a particular way what I'm really doing is > adding the ability for the author of a WikiItem to define an > explicit for his WikiItem (as versus being a purely abstracted > node), and for others to then explicitly place that WikiItem and > others in new contexts without invalidating or altering the > original context, and to then allow those contexts to be > manipulated as definitions in their own rights. There's a missing word in the second sentence. It should read: When viewed a particular way what I'm really doing is adding the ability for the author of a WikiItem to define an explicit __CONTEXT__ for his WikiItem (as versus being a purely abstracted node), and for others to then explicitly place that WikiItem and others in new contexts without invalidating or altering the original context, and to then allow those contexts to be manipulated as definitions in their own rights. -- "Finally coming home" Home: cl...@ka... J C Lawrence Other: co...@ka... ----------(*) Keys etc: finger cl...@ka... --=| A man is as sane as he is dangerous to his environment |=-- |
From: J C L. <cl...@ka...> - 2000-07-03 22:56:57
|
On Mon, 03 Jul 2000 15:46:00 -0700 J C Lawrence <cl...@ka...> wrote: > Agreed. When viewed a particular way what I'm really doing is > adding the ability for the author of a WikiItem to define an > explicit for his WikiItem (as versus being a purely abstracted > node), and for others to then explicitly place that WikiItem and > others in new contexts without invalidating or altering the > original context, and to then allow those contexts to be > manipulated as definitions in their own rights. There's a missing word in the second sentence. It should read: When viewed a particular way what I'm really doing is adding the ability for the author of a WikiItem to define an explicit __CONTEXT__ for his WikiItem (as versus being a purely abstracted node), and for others to then explicitly place that WikiItem and others in new contexts without invalidating or altering the original context, and to then allow those contexts to be manipulated as definitions in their own rights. -- "Finally coming home" Home: cl...@ka... J C Lawrence Other: co...@ka... ----------(*) Keys etc: finger cl...@ka... --=| A man is as sane as he is dangerous to his environment |=-- |
From: Arno H. <aho...@in...> - 2000-07-04 20:11:05
|
> Perhaps I should restate my original post. What I listed are some > of the things I'll be doing. I'm starting from a base of PHPWiki. Understood - I thought commenting from our standpoint makes sense in order to help you see differences and common ground. I now better understand the intent of your changes. Quite intersting. Actually, I'm all in favour of wiki taking over the web :o) > Agreed. When viewed a particular way what I'm really doing is > adding the ability for the author of a WikiItem to define an > explicit context for his WikiItem (as versus being a purely abstracted > node) I'm sure you have looked at the node typing of everything2? Some good ideas in there too. /Arno |
From: J C L. <cl...@ka...> - 2000-07-04 22:49:07
|
On Tue, 4 Jul 2000 22:10:17 +0200 (MEST) Arno Hollosi <aho...@in...> wrote: >> Perhaps I should restate my original post. What I listed are >> some of the things I'll be doing. I'm starting from a base of >> PHPWiki. > Understood - I thought commenting from our standpoint makes sense > in order to help you see differences and common ground. Oh, absolutely, and I agree. That was the intent of my original post -- to see if there was some basis of cooperation between the two projects given that they share a common root. <bow> > I now better understand the intent of your changes. Quite > intersting. Actually, I'm all in favour of wiki taking over the > web :o) <dissemble> Well, umm, golly gosh. </dissemble> Actually the intent of this project from my end is to act as the foundation for what in essence becomes a human-centric knowledgebase where the concentration is on individual evaluation and discrimination among items without distinction between original items and meta-items. >> Agreed. When viewed a particular way what I'm really doing is >> adding the ability for the author of a WikiItem to define an >> explicit context for his WikiItem (as versus being a purely >> abstracted node) > I'm sure you have looked at the node typing of everything2? Some > good ideas in there too. Actually, until you mentioned it, no. Yes, some very good ideas in there. That's going to take some study. Thanks! -- "Finally coming home" Home: cl...@ka... J C Lawrence Other: co...@ka... ----------(*) Keys etc: finger cl...@ka... --=| A man is as sane as he is dangerous to his environment |=-- |
From: Jeff D. <da...@da...> - 2000-07-04 01:26:08
|
Arno Hollosi writes: > J C writes: > > > -- Page histories with prior versions view available (encluding > > ownership changes). > >We already have a diff in 1.1.6 - only the prior version though. >I assume that eventually this will develop into a full versioning system. (Erratum: As of now diff is only in the CVS version, not 1.1.6(b).) I just checked a new wiki_diff.php3 into the CVS repo. It's faster than the previous one (which did turn out to be an issue.) Also I've added the compose() (and reverse()) method to class WikiDiff, so it's all ready to be used in a full versioning system. "All" that needs to be done now is to fix the db access API and schema so that multiple backup versions can be saved. I can work on that (particularly for the MySQL and DBM drivers) if I'm not stepping on any toes. > > -- Inter-version colourised diff-style views available of edited pages > >Nice gimmick. Maybe Jeff is willing to implement this. Unless I misunderstand, this is there now (in the CVS version.) You can try it out on http://phpwiki.sourceforge.net/1.1.6/ (standard diff version) or http://www.dairiki.org/HammondWiki/ (unified diff version). Jeff |
From: Arno H. <aho...@in...> - 2000-07-04 20:21:46
|
> I just checked a new wiki_diff.php3 into the CVS repo. It's faster > than the previous one (which did turn out to be an issue.) Also I've > added the compose() (and reverse()) method to class WikiDiff, so it's all > ready to be used in a full versioning system. Great. > "All" that needs to be done now is to fix the db access API and schema so > that multiple backup versions can be saved. > I can work on that (particularly for the MySQL and DBM drivers) if > I'm not stepping on any toes. You won't be stepping on mine and I'm sure Steve doesn't ind either. Go ahead :o) > > > -- Inter-version colourised diff-style views available of edited pages > > > >Nice gimmick. Maybe Jeff is willing to implement this. > > Unless I misunderstand, this is there now (in the CVS version.) Your latest changes are indeed a step torwards that direction. What I was thinking about is, e.g. diffs of version 5 against version 17 (not only version 16 against 17). Also, I understood the above as a diff page, that looks like the original wiki page (through wiki_transform), only with the diff changes highlighted inside the wiki-page. Currently wiki_diff shows diffs from the wiki source markup. I'm ok with that. The other way would need some major modifications to wiki_transform and some to wiki_stdlib and I don't really think it's necessary. THere are more important things to be implemented. /Arno |
From: Steve W. <sw...@wc...> - 2000-07-05 00:45:14
|
On Mon, 3 Jul 2000, Jeff Dairiki wrote: > I just checked a new wiki_diff.php3 into the CVS repo. It's faster > than the previous one (which did turn out to be an issue.) Also I've > added the compose() (and reverse()) method to class WikiDiff, so it's all > ready to be used in a full versioning system. Great work! :-) > "All" that needs to be done now is to fix the db access API and schema so > that multiple backup versions can be saved. I can work on that (particularly > for the MySQL and DBM drivers) if I'm not stepping on any toes. Not at all. I think that when a project stops refactoring code because the developer whose code gets changed throws tantrums is the day that project dies. Always feel free to question design choices; I do :-) For the record I also want total versioning down to the first version. However the point I differ on (my personal opinion) is that storage space is cheap, Wikis are just text, so why not save the whole thing? Not every little edit change though. Let me explain. Right now we have a store of live pages and a store of their last version. When a new author saves the page the new version goes live, the current live page goes into the archive, and the last version is lost forever. What if the last version is not lost, but stays in the archive? We have all the previous versions by the previous authors; little edits the current author makes don't get archived (I know when I edit a Wiki page I make at least two saves and usually more). How much room does this take up? A fairly long page on c2.com is http://c2.com/cgi-bin/wiki?LordOfTheFlies. It's 14234 according to Netscape. Let's say the page is very active, and there are 100 edits over its lifetime... that's over a meg of data. That's probably a worst case senario; most pages don't see that much activity. Another good yard stick is Ari's Wiki. It's using 23 megs right now, and because DBM files keep every copy they ever had, and Ari's wiki is *really* active, I think that's pretty good in terms of space (sadly, all previous versions are lost in the DBM file). Now, how much work is it to: * Store only the diffs of the pages * Recombine them when someone wants to see the differences between version 1.1 and version 1.99? If it's not much work at all (on the programmer (Jeff :-) and the server) then I think only storing diffs is a Good Thing. If 50-100 megs for a Wiki sounds accessive, storing only diffs is a Good Thing. If the problem is also one that simply interests you and you don't care what benefit it has for PhpWiki it's also probably a Good Thing (for you :-) I think we can stick with the "archive" table for this and the user will see no changes in behavior, other than being able to retrieve any previos version of the page. I am going to go into this more in a separate post, but first I have to check with my friends to see if we are still going to see the fireworks. I had jury duty last week and took one of my favorite Wiki idea books along, Jon Udell's "Practical Internet Groupware." (See my review at http://www.amazon.com/exec/obidos/ASIN/1565925378/qid%3D962757399/104-0556265-3752700) . It gave me an epiphany regarding saving versions... sw p.s. my other favorite idea book is Philip and Alex's Guide to Web Publishing, which is more of an opinion book than a technical book: http://www.amazon.com/exec/obidos/ASIN/1558605347/qid%3D962757580/104-0556265-3752700 ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |