Happy Birthday Ellen!

Hard to believe this was two years ago. Or that now she can do this when you ask her to make an angry face:

 

 

 

:)

 

Happy birthday sweetie!

The Impact of Atlas on Web Services

<prognostication-mode accuracy="questionable"> 

 

I was reading this post today about the Microsoft AJAX Library, and something struck me: the [ScriptService] attribute makes this is a new web service toolkit. "Duh", you're saying. But the interesting thing about this one is that it's a toolkit that .NET web service authors probably can't ignore. Up until now, I've been getting the message from most of my clients that the only web service client they really care about is .NET. That sort of begs the question of "Then why use web services at all?" but that's perhaps a topic for another time.

 

At any rate, given how software from Microsoft is usually received by developers in the Windows world, I suspect that people will be forced to consider the AJAX Library when designing their .NET web services. And granted it's written by the same company, but I'll be completely stunned if the two stacks are completely isomorphic. Hell, it's hard enough to get the .NET stack to talk to itself across XML serialization sometimes.

 

I think this constraint is going to be fundamentally positive. It's generally true that the second client is much harder to write than the third, as the number of generalizations you have to introduce decreases. So if people start testing against two different clients (even if they are both from Microsoft) then it'll be that much easier when it comes time to integrate with Java, or Ruby, or whatever the hell comes next. Which is (at least one of) the point(s) of doing Web Services.

 

Should be interesting. At the very least, it looks like I should devote some time to playing with [ScriptService] to find out what the limitations are.

 

</prognostication-mode>

ScrewTurn Wiki

Ian pointed me to this posting by James Avery, who seems to really like ScrewTurn wiki, an open-source, .NET-based wiki engine just like FlexWiki. But James' statement

 

I have been using FlexWiki for sometime and I have to say that Screwturn really blows it away. It has built in security, one-click backup, its extremely customizable, and much more.

 

sort of caught my eye, as you might imagine. :)

 

Contrary to what seems to be the unfortunately frequent open-source practice, I'm not interested trashtalking ScrewTurn wiki. In my ideal world, ScrewTurn would do everything that FlexWiki does, plus more, and there'd be a syntax converter. Then I could switch to ScrewTurn wiki and spend my limited free time making it (or something else) better. Since that doesn't seem to be the case (it looks like they both have features the other lacks), I guess I'm going to stick with FlexWiki for now. :)

 

At any rate, if you're in the market for a .NET-based wiki, I highly recommend you check out ScrewTurn. I haven't installed it yet, but I've skimmed the docs, and it sure looks like they've got a solid project. It looks like for now the choice between FlexWiki and ScrewTurn depends on your particular requirements and preferences, so it's good to know about the options.

 

And to any ScrewTurn devs that read this - if there's anything FlexWiki can do to help, or if you have suggestions about what we can do better (there's lots), or if you can think of interesting ways to work together, just let us know.