my two cents on the DB thing. I understand that, depending on your situation, you may want flatfiles and other times a database works better. I would suspect that over time I would find a need to use both. At this point in time however I prefer the simplicity of the flat files for storage. If we can make dokuwiki be configurable to support either one (or even a mix of both??!?) that would be great. Just dont forget about the flat files. :) On 7/24/05, Redeeman <redeeman@xxxxxxxxxxx> wrote: > i am currently implementing very ugly, but hopefully working db storage > support, just for test, using PEAR::DB, so basically all databases are > supported.. > > On Sun, 2005-07-24 at 09:36 +0200, Redeeman wrote: > > hello. > > i have been briefly looking at the plugins and mysql database storage > > this month on the list, and it seems clear that people want mysql > > storage, and plugin support for everything. > > > > i have also been peaking through the code of dokuwiki, and it seems abit > > monolithic. > > > > i am myself using dokuwiki, and think its great, but i am concerned > > about reading that it doesent handle many pages well (searching). > > > > and also, i found the way the wikify parser works alittle bit unmodular. > > > > now dont get me wrong, i love dokuwiki, but i think this could be > > improved, and i would love to help.. > > > > what i propose: > > it should use a database class(or just functions) to fetch/store > > everything, and then we can just copy the existing things into a > > flatfile version, and create a PEAR::DB version, which will then support > > basicallly all databases(sqlite,postgresql,mysql,sybase...), the > > difficult task in this will be to split it out from the current > > dokuwiki, writing the class/functions should not be a problem.. > > > > plugins/modularity: > > i suggest making dokuwiki a sort of plugin base, and then ALL > > functionality is written as plugins. so that each thing in a wikipage is > > processed via plugins, this might even reduce load, since we only load > > plugins which are needed to parse the output (we could have a file with > > description of what the plugin can parse).. this atleast would be great > > for the structure of the dokuwiki code, it would look even greater, and > > be alot easier to extend.. > > > > these things will probably take abit time, but i am willing to help, and > > with the database thing another guy offered to write db storage, but, > > give me your thoughts, and we can discuss things, and perhaps come up > > with a plan on what to do, to enhance the GREAT product dokuwiki :D > > > > Regards, > > Kasper Sandberg > > > -- > Redeeman <redeeman@xxxxxxxxxxx> > > -- > DokuWiki mailing list - more info at > http://wiki.splitbrain.org/wiki:mailinglist > -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist