Share via


In this corner... (and $100)

The great thing about this position is that I get to pay attention to all of the conversations folks are having about WF.

The bad thing about this position is that I get to pay attention to all of the conversations folks are having about WF.  I'm still learning how to listen to everything and anything that's going on in the world of WF, so forgive me for being a little slow to respond.

Brian Noyes started off with this post last Wednesday about the complexities inherent in WF, which was followed by Scott listing some of the common gotcha's in WF development.  Tomas also has two posts (part 1 and part 2) on the subject.  Jon weighed in somewhere in the middle there discussing some of the points raised.  Some interesting comments are being posted to Jon's and Brian's posts.

For me, this is really rewarding to see the community having these conversations about the technology.  Please keep having them, and if you have feedback, post it into our connect site.  These things get routed directly to the team.  Things are pretty much ready to go on v1, but that means we're working on planning what vNext and beyond are looking like, and we need to hear these things!

That being said, there is complexity in our model, and a lot of that comes from being extensible enough to manage the logic of your Windows Forms app using the same engine that runs the document life cycle workflows in MOSS. I think this is the benefit of providing this "foundational" api to enable workflow in any application, but it does come at the cost of a learning curve and complexity, and there are valid arguments whether certain pieces of complexity are neccessary.  So, what do we do about it?  Let's have a real informal $100 exercise.  Basics of the exercise here:

You have $100 engineering dollars to spend.  No matter how many millions we'd actually wind up spending, we use $100 as an easy number for people to keep in their heads.

There are well over $100 dollars worth of features you want.

The challenge is in determining how to spread the $100 in a way that produces with the most aggregate value.

What would you like to see added, improved, "fixed" in WF? Some thoughts, but don't feel limited to these: [Standard disclaimer: These are just my ideas, and nothing here means it will become part of the product.]

  • Providing out of the box hosting for certain scenarios (eg: Windows service, WCF, ASP.NET)
  • Management tools (what would these look like?)
  • WF for client workflow scenarios (like Apple's Automator?)
  • Application Scenarios (eg: page flow)
  • Activity libraries (what kind of activities?)
  • Tooling (better spawned context awareness [what would that look like?]?, different project templates, etc)
  • Guidance

Post away!

Comments

  • Anonymous
    August 22, 2006
    Matt,

    see my comments here
    http://www.winterdom.com/weblog/2006/08/22/100ToSpendOnWF.aspx
    :)
  • Anonymous
    August 23, 2006
    The WF discussion that Brian Noyes kicked off continues with excellent points from Jon Flanders and Thomas...
  • Anonymous
    August 25, 2006
    Here is my wishlist:

    Guidance on integration between LINQ/ESQL and WF. In particular, a way to access entities in a declarative way from WF. I want to create my data layer with entities and business layer with WF. I think this should be one of the primary use cases for WF and the tooling should support it as much as possible.

    Beyond that, the vision of using WF as the core of the next version of ASP.NET is great. I would concentrate on that instead of trying to use WF in the current version.
  • Anonymous
    August 30, 2006
    The comment has been removed
  • Anonymous
    June 08, 2009
    PingBack from http://quickdietsite.info/story.php?id=452