Thomas Wittek wrote: > > Good ideas. But maybe we should start a bit smaller ;) > It might be a good idea to create a list of features separated in > several increments (releases) to get a running system early.
Absolutely. > I could imagine increments like "Parsing/Converting", "Storage > backend/Revision control", "User management", ... > > Unfortunately you probably have to throw away/heavily modify earlier > increments, if you add features like a flexible syntax, which will need > a different internal infrastructure. Well, if object-oriented design has any advantage at all, here it is! If we design this sort of wiki from the very beginning in a way that you can just "load" a sort of storage backend, user management, rule engine (per heritage or plugin-wise) you can start off creating the simplest storage, a nearly nonexistent usermanagement and a very simple rule engine and just swap when you've got a better one in stock ;) Only you will have to define the abstract class or plugin bay from the first minute in the right way (the "only" was softly ironic). > But targeting such a "feature monster" will probably take too much > development time. I agree heavily. I only propose a flexible object-oriented or otherwise modular design that enables programmers to weld stuff onto it and plug other stuff into it and after transformation use it from outside as a module to do something with it that noone has foreseen... Ok, forget about the last bit, I'll be content with welding and plugging ;) > Maybe a "feature complete" version could be targeted as "the" > Perl6-Wiki-Software. > But before this one a "Lite Version", which will be used to have a wiki > quickly available, could be developed. > > -Thomas Maybe, just to get started, we should use as many perl5-modules as we can and then substitute them one by one (thinking of CGI, YAML, DBI, HTML::Template, etc., etc.) Regards, Udo -- That which is not good for the bee-hive cannot be good for the bees.
