I seem to say this every few months, but this is a pretty major milestone on the long, long road to FlexWiki 2.0. Specifically, this is the first release where essentially everything from FlexWiki 1.8 works again. So the RSS feeds, the newsletters, and the administration pages have all been repaired, which is nice. The one thing that's still broken is the SqlProvider. Since most people use the FileSystemProvider, I don't think that's a huge deal. I'm fixing the SqlProvider even now, and it will be present in FlexWiki 2.0 Beta 2.
The major new feature in Beta 1 is the security infrastructure. FlexWiki now sports topic-level security. That means you can put something like this
AllowRead: user:candera
DenyEdit: anonymous
in a topic and it'll work. You can also do this sort of thing on a per-namespace basis, or wiki-wide. It works with either Windows or Forms authentication, and I've even thrown in a simple implementation of some login/logout pages for people that want to get something simple set up for Forms authentication.
If I seem excited about the security stuff, it's because I am: the whole reason I ripped FlexWiki apart (starting nearly two years ago!!) was to make it possible to add security in a maintainable fashion. Now it's done.
You can read more about the new security features here.
As far as the road ahead, there are really only two tasks remaining before I can shove FlexWiki 2.0 RTW out the door:
- Fix the SqlProvider.
- Analyze and tune performance.
I've already started the SqlProvider work, and I don't expect too many problems. Performance could be easy or could be hard - I'll need to start by comparing the performance of the 2.0 bits with the 1.8 baseline. That'll tell me how much work I have to do.
But any way you slice it, the release date for 2.0 RTW is a whole lot closer than it used to be.
Certainly looks like interesting and exciting work and would not mind trying it out. All the best with nailing it..
ReplyDeleteMy question is how hard it would be to take already formed output like xhtml, some xml files and so on, and adding your own role-based (ms sql's own, within its tables or other) and transferring the content on the FlexWiki?
I am looking for least pain possible with integration, and wonder what kind of work it would involve in your opinion.
Cheers.
If you already have XHTML, the hard part is turning it into FlexWiki's format (informally called WikiText). The two formats are by no means isomorphic. As one random example, WikiText does not support background images.
ReplyDeleteSo it really depends on the content. We've done manual porting efforts before where we had volunteers do it by hand, and it wasn't too bad, but that may or may not work for you.
I'm not 100% sure I understand what you're trying to do, though. Does my answer make sense?
Yes it does Craig, thanks for your time.
ReplyDeleteI believe I saw FlexWiki having pretty much the standard table tags bloat and that is a turn off to begin with. Sure, some tools to deal with CSS output are out there..
I have my own permissioning defined, it can be in xml or elsewhere (standard tools), other tools do their job on outputing different xhtml pages and so on, it all changes daily. I wanted to drop this into a wiki and ideally integrate two authoring processes (machine and human), slap on some control and versioning, hence my inquiry.
Reading however manual work might be required is a no-go.
Speaking of ASP.NET turn-off in general, while MS as is looking at profiles, network service bits and more while their CLR is banging with 0x80131506 (Fatal Execution Engine Error), I
believe it is all to do with state of x64 support.
In any case, thanks for your input once again.
Cheers,
6 _
If I understand correctly, integrating with what you have would require either porting your content or writing a new provider for FlexWiki. The rearchitecture work I did enables the latter path, but I couldn't say for sure how easy it would be, or even if it would be possible. I'm guessing it would be pretty hard.
ReplyDeleteAny chance of writing a step by step procedure for upgrading from FlexWiki 1.8 to 2.0.
ReplyDeleteMy organization has grown very dependent on our internal FlexWiki, and we can't afford to loose any data, functionality, or bear much downtime (a working day might be OK)
We use the FileSystemProvider, with multiple namespaces.
BTW Does Flexwiki 2.0 support per page RSS? (That would be a really valuable feature, because the wiki could act as a blackboard to disseminate specific information)
The security features sound very promising. I can see that this feature may elevate our use of FlexWiki to a more official corporate level.
Thanks for your fantastic work on FlexWiki. I know working on OS projects is time demanding.
-- Phil
I'm not planning on doing any of the documentation until I'm closer to release, because that way I don't have to update it when I change something.
ReplyDeleteIf you're using the FileSystemStore, the upgrade should be pretty painless. The only thing you should have to do, in fact, is move the FlexWiki settings from NamespaceMap.xml and web.config to flexwiki.config. Eventually I intend to automate this, but for now it's a manual process. I don't expect it will take you more than an hour.
Re: per-page RSS. That's supported now, but you have to create a newsletter that references the page. Every newsletter also has an RSS feed.
Let me know if you need any help.