Just an update since it's the beginning of a new month.
I see Philip(fuzzy_logic) has updated his plans as well ;) But for those wondering, my project was never to compete with his, in fact, he revived his at just about the same time I got an interest in this through registering a domain name. We talked, he wanted to develop on his own. Competition/choices are good. I have no problems with that.
But, in the past month, I've done a lot of surfing, reading, and playing with Wiki's as opposed to 'blogs' (and not a lot of sleeping). My goal, for all this, was much more wiki-like than blog-like. I don't need/want the spammish announce type features, but I wanted to be able to allow a user to post/set up a news or diary page, and allow interactive comments on them. With a wiki, the ability to allow free-form editing is also possible.
I have set up a couple of blogs, and quite frankly, don't like them at all. It's not "me". I like to code things I like. Something about the blog seems stunted.
I've set up 4 or 5 different wikis, and while I don't like any of them, I *do* like the concept. They are collaborative, which translates to interactive, which translates into "stickiness" for surfers.
What don't I like?
First, almost all development of SQL backed wiki's is in PHP. The "H" stands for "HOLES". I don't like code in the web tree.
Second, PERL wikis use too many system hacks and do most things in a flat-file format
Third, security on them is not well thought out, and relies on .htaccess and RCS revisions roll back.
Forth, they all have their own rendering, parsing, and access utilities.
So, my goal, is to take the concept, and use Links/GT code to do most of the work of managing users and access, parsing the templates, and accessing the database.
How I do that has been holding me back.
I don't want to reinvent the wheel, so I have to take the GNU/GPL rendering (syntax parsing code) and put it into a stand-alone module that can be accessed from another program. This is *not* my strong point, and anyone who would like to take on that job would be rewarded handsomely in many ways. This is the code that takes the WikiStyleWords and turns them into linkable objects, and deals with the [[]] formatting, etc. There is really no reason to write another engine, just condense and modularize the existing ones as a stand-alone module. Any "fixes" to the original modules could be easily applied, and under the GNU/GPL terms, this is allowed.
Ignoring that issue for awhile, the larger concept of how to work this into Links has been troublesome.
I don't want to start off with an OEM version of Links, eg: Blinki-Wiki or Blinki-Blogger that requires a whole license, but rather as a plugin that simply allows the users to set up their own system as described in the "blogger" posts above.
The difference is, that the spam features won't even be considered, and there will be an option for interactive edits of the comments and pages, not just simple post.
The issue then becomes do I allow all these mini-wikis to interact with each other, or just be limited to their own data.
Because I'm paranoid, and like security, they won't be free-for-all.
Users will have to register to edit.
Edits can be moderated (eg: approved before applied)
Edits can be rolled back to a point (maybe 7 generations, and/or days whichever is LONGER)
Users can be blocked from editing the original comments, or others comments, etc. (eg: a normal, non-wiki system)
Users can be allowed to edit the main topic (original comment) but not the comments posted by others. (I sort of like that)
It really starts to get hairy here, since it begins to look more like a bunch of porcupines tossed into a small box, than a top-down, tree-like, or even web-like system.
The comments plugin will be released, soon! I'm fixing up the pre 3.0.1 template issues, and cleaning up some calls. This "Blinki" idea will start to extend from this plugin, but the plugin will also be left "as is" with improvements for those who just want comments.
If someone would like to work on the syntax parser, I'd really appreciate it, as would a lot of others I'm sure. Not just links users. Since this is all GNU/GPL code, it can be released back to CPAN with attributions, and be a useful module/addition to the tools there. Reinventing this is pointless, and it's a potentially really useful tool for everyone, so if there are no takers here, I'll have to try to find a kid this summer who needs a project. Basically, the "content" block of the displayed page, what would be contained in the current "Description" field, would have to be parsed for tags. A block of raw text in, a block of parsed/replaced text out. Many good brains have worked out all the regexes (well, most of them <G>), it's just a matter of collecting them, and applying them in a reusable modular form, and releasing them back to the community at large.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
I see Philip(fuzzy_logic) has updated his plans as well ;) But for those wondering, my project was never to compete with his, in fact, he revived his at just about the same time I got an interest in this through registering a domain name. We talked, he wanted to develop on his own. Competition/choices are good. I have no problems with that.
But, in the past month, I've done a lot of surfing, reading, and playing with Wiki's as opposed to 'blogs' (and not a lot of sleeping). My goal, for all this, was much more wiki-like than blog-like. I don't need/want the spammish announce type features, but I wanted to be able to allow a user to post/set up a news or diary page, and allow interactive comments on them. With a wiki, the ability to allow free-form editing is also possible.
I have set up a couple of blogs, and quite frankly, don't like them at all. It's not "me". I like to code things I like. Something about the blog seems stunted.
I've set up 4 or 5 different wikis, and while I don't like any of them, I *do* like the concept. They are collaborative, which translates to interactive, which translates into "stickiness" for surfers.
What don't I like?
First, almost all development of SQL backed wiki's is in PHP. The "H" stands for "HOLES". I don't like code in the web tree.
Second, PERL wikis use too many system hacks and do most things in a flat-file format
Third, security on them is not well thought out, and relies on .htaccess and RCS revisions roll back.
Forth, they all have their own rendering, parsing, and access utilities.
So, my goal, is to take the concept, and use Links/GT code to do most of the work of managing users and access, parsing the templates, and accessing the database.
How I do that has been holding me back.
I don't want to reinvent the wheel, so I have to take the GNU/GPL rendering (syntax parsing code) and put it into a stand-alone module that can be accessed from another program. This is *not* my strong point, and anyone who would like to take on that job would be rewarded handsomely in many ways. This is the code that takes the WikiStyleWords and turns them into linkable objects, and deals with the [[]] formatting, etc. There is really no reason to write another engine, just condense and modularize the existing ones as a stand-alone module. Any "fixes" to the original modules could be easily applied, and under the GNU/GPL terms, this is allowed.
Ignoring that issue for awhile, the larger concept of how to work this into Links has been troublesome.
I don't want to start off with an OEM version of Links, eg: Blinki-Wiki or Blinki-Blogger that requires a whole license, but rather as a plugin that simply allows the users to set up their own system as described in the "blogger" posts above.
The difference is, that the spam features won't even be considered, and there will be an option for interactive edits of the comments and pages, not just simple post.
The issue then becomes do I allow all these mini-wikis to interact with each other, or just be limited to their own data.
Because I'm paranoid, and like security, they won't be free-for-all.
Users will have to register to edit.
Edits can be moderated (eg: approved before applied)
Edits can be rolled back to a point (maybe 7 generations, and/or days whichever is LONGER)
Users can be blocked from editing the original comments, or others comments, etc. (eg: a normal, non-wiki system)
Users can be allowed to edit the main topic (original comment) but not the comments posted by others. (I sort of like that)
It really starts to get hairy here, since it begins to look more like a bunch of porcupines tossed into a small box, than a top-down, tree-like, or even web-like system.
The comments plugin will be released, soon! I'm fixing up the pre 3.0.1 template issues, and cleaning up some calls. This "Blinki" idea will start to extend from this plugin, but the plugin will also be left "as is" with improvements for those who just want comments.
If someone would like to work on the syntax parser, I'd really appreciate it, as would a lot of others I'm sure. Not just links users. Since this is all GNU/GPL code, it can be released back to CPAN with attributions, and be a useful module/addition to the tools there. Reinventing this is pointless, and it's a potentially really useful tool for everyone, so if there are no takers here, I'll have to try to find a kid this summer who needs a project. Basically, the "content" block of the displayed page, what would be contained in the current "Description" field, would have to be parsed for tags. A block of raw text in, a block of parsed/replaced text out. Many good brains have worked out all the regexes (well, most of them <G>), it's just a matter of collecting them, and applying them in a reusable modular form, and releasing them back to the community at large.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
