IWikiData

1. Do you think this is a good idea?

2. What would the interface look like?

3. What would be the best place to configure this?

DavidOrnstein's thoughts

I'm not sure it's needed. FlexWiki uses pretty good caching. We'd need evidence that the current solution isn't good enough. That said...

The ContentBase class is designed specifically to serve this architectural function. Almost everything about the fact that it's a file system instead of a database is isolated in this class. The model I had in my head was that ContentBase would become abstract and there would be a file-system subclass and a database subclass. Of course, that assumes that we need a DatabaseBackend.

BryantLikes's thoughts

The file system is certainly good enough. However, some people (like myself) store everything in a database . So maybe we don't need it, but it might be a nice feature...

JasonDossett's thoughts

I would only expect an IWikiData if there was any reason for the data to be strongly typed. Does it? Maybe IWikiDataProvider instead? Or some place in the engine that supports substituting a different data provider based on the standard ADO.NET interfaces.

Well, the data that FlexWiki sees should have a consistent schema. The implementation of IWikiData could easily be written to call into the abstract ADO.NET classes that are not provider specific, and load the actual implementations (SqlConnection/OracleConnection, etc.) based on a factory call that checks a config file. IOW, it's not difficult for the implementation to be database-agnostic -- JoshuaAllen

DavidCornelson's thoughts

I think the wiki format is more suited to something like Word->SharePoint. A database seems to harden what to me is a loosely-coupled text driven asynchronous file editor (LCTDAFE). I like databases and some business environments might require a database backend, but I believe that a file based is natural. And when Mono is more durable, this could be ported to linux without a lot of trouble.

BenediktEckhard's thoughts

I'm very new to FlexWiki, but I think a IWikiData interface would be really nice. Specially in scenarios (like mine) where you have some space on a webserver and much more space in some database. in web.config one could specify which dataprovider to use and where it should connect to (maybe connect to a backup database if the main one is down). Also for clearity it would have some advantages: All the common classes and interfaces in the engine project, and everything specialized (also the formatters) in its own assemblies. (like in hurricane - http://www.projecthurricane.com)

JoshuaAllen's thoughts

There are some significant benefits to having stored in a database:

• Enable new features on Wiki frontend. For example, query to show all pages that have not been updated in 'X' days which are linked from 'foo'. Currently the indexing is hard-coded and supports only certain queries.
• Enable better integration with other sources of data. For example, could auto-generate Wiki pages from other data sources by storing in Wiki's db. Could extract info from Wiki pages more easily to join to other data in other databases.
• Management. Could use database security management features to allow granular access, filter lists of links to show only links with permissions, etc. Could have better control over backup, restore, and replication of subsets of data across multiple sites.
• Shared hosting. Many shared hosting sites will offer database access, but not file-write permissions.
• Filesystem is brittle -- all of these files scattered around, and when one gets corrupted it is very difficult for the user to debug. This is a problem that plagues SourceSafe, FrontPage SE, dasBlog as well, and not just a good vs. bad programmer issue. It comes with the territory when implementing your own database and indexing technology on top of filesystem.

I would imagine a very simple schema -- a pages table consisting of PageId with a CLOB for the text, and separate 1-many tables for properties and links for each page. Mono already has a data access stack, and the schema seems simple enough that it could easily be database-agnostic (at least across SQL Server, Oracle, and MySql, all of which have managed providers). And besides, other non-Windows platforms have database-backed Wikis, so it's not that tough to do.

MikeSchinkel's Thoughts

I too would really like to see a database backend as I agree with JoshuaAllen's comments. Actually, I think an IWikiDataProvider as JasonDossett suggests makes the most sense; that way those interested in the file backend can have if, and those who want/need a database backend can have it too. If I were to spend some time formalizing my thoughts I feel I could give severaal more reasons why having the option of a database backend makes sense (as is I have pretty strong gut feelings about it.) JoshuaAllen mentions the problems with dasBlog; I'm using it for my blog at the moment but plan to move off it it very soon to .Text because of the flexibility .Text provides with its database backend.

BTW, I am ready to immediately provide the programming support to get this done (but I will only have the resources for two months, so will need to move on it.)

VincentYang's Thoughts

I think having an option to store data in SQL/DB is very important for this software. Most of the ISP will not allow user to have access to their folders. They will provide DB support, and provide interface to access the SQL to control user access, but not support manage folder ACL.

Having write access to the host machine is a huge security threads the most companies will not be able to justify. This will limit the adoption rate of FlexWiki to only user hosting on their own box.

JamesRoeSmith's Thoughts

Check out the ThreeWikiFormats topic which relates to this content.