WinFS Scenario #3: focusing your dev time on what really matters


Wikis seem to be catching on some at Microsoft.  Several product teams are using Wikis to brainstorm features and product design, or even more mundane things like recording meeting notes.  I love the simple collaborative nature of a Wiki, the openness that just invites every ready to contribute and respond to one another.


 


One thing I don’t like about Wikis is how they work when I’m on offline — which is that they don’t work at all.  All the goodness of that collaborative web of data is trapped up on the server, and unless I’ve got a connection back to the corporate network, I can’t see any of it.  Even when I am online, if I’m want to edit several entries, it slows me down to have each click launch a round trip, and wait for the server to return with the next page.


 


Others have observed the same shortcomings, and have started Wiki client projects here and there.  JHorman seems to have wanted the disconnected Wiki experience so much that he built a personal Wiki-like notepad app.  These are all neat client apps, and I’m glad to see them on Windows today, but I suspect they required a lot of code to handle storing the data on the local client.


 


So for my third not-bad WinFS scenario, I figured I’d taking an existing scenario – the local Wiki client – and talk some about how the WinFS platform would simplify the development process.


 


At the core of FwSynch and WikidPad must be some sort of data engine.  You’ve got a collection of distinct Wiki entities, and a web of keyword relationships between them.  How do you persist them on the client?  How do you track changes on the client and synchronize them with changes on the server?  Will your storage architecture be performant —  how long will it take to boot the app and display an entry?  Will the performance scale as the number of entries end edits reaches the hundreds, or thousands?  Is your storage format able to recover if a small portion of data becomes corrupted?


 


There are plenty of options for client storage today, of course.  The simplest solution might be to store all the data in a big XML file.  Maybe you’re more comfortable with relational DBs than with XML’s hierarchical storage concepts, so instead you redistribute a DB engine like MSDE or SleepyCat’s Berkeley DB.  Maybe you’ve got the right skill set to build your own custom storage engine.  Each of these has its own tradeoffs across development time, feature set, and performance characteristics. 


 


But, no matter what you choose, you will end up spending development time on something that is, in all likelihood, not a competitive differentiator.  If you were building a competitor to WikiPad, where would you focus your energy on creating a different and more valuable product – would it be in tuning the performance of the storage engine, or would it be in improving the UI, or editing experience, or adding new features?  If you were building a competitor in the music player market, going up against iTunes, MusicMatch and WinAmp, etc, would your distinguishing features be around visualizations, skinning, and play list management, or would they be around storage optimizations?


 


I’d argue that for most desktop applications, performance of the storage engine is generally not a competitive advantage – you’re not going to sell users on switching to your software just because it’s 10% faster than the other guy.  Performance can be a disadvantage, if you’re the slowest app in the pack, but the goal in that case is just to catch up to everyone else so that you can get the same check mark in the performance column as all your competitors.


 


There are, of course, some apps whose main value-add really is performance – if you’re building a client search app like X1, then it’s probably worth spending a lot of dev cycles to eke out a 10% perf gain over your competitors.  But for apps that manage music, photos, or Wiki entries, I think the real-value add is in the features and user experience, not the perf.  I’m looking forward to reading everyone’s opinions in the comments, but really, have you heard of anyone switching from Quicken to MS Money (or vice-versa) because checkbook register look-ups happen a few milliseconds faster?


 


So how does WinFS help out?  It provides an integrated storage engine that’s built into the platform, and which has been tuned for client performance by a dedicated team of storage experts.  It’s has a schema and data model that’s built specifically to store relationships between items.  As a core part of the WinFX platform, you can expect there to be a good set of tools from Microsoft and others to help tune the performance to suit your particular application.  And if your app has to synchronize with data from a server, WinFS is built from the schema on up to support the notion of efficient synchronization, and has an extensible provider model for communicating with whatever your server back-end may be.


 


All in all, less time spent on developing storage infrastructure, and more time spent on building the real value-add features of your next great application.  This isn’t quite as exciting as the last two scenarios, since they really focused on adding those killer new features, but I’m hoping that a lot of people will indeed breathe a sigh of relief when there’s a decent storage engine in the Windows platform, and they can turn their focus to more important matters.

Comments (16)

  1. Louis Parks says:

    I don’t see this as a good scenario for a few reasons.

    You mentioned XML and MSDE. With XML, MSDE, and WinFS, according to this scenario, the app developer will still have to develop a custom schema (does WinFS have a schema def for every possible attribute I need to search on in my Wiki app?). They all support data storage, relationships, retrieval, updates, etc. They all have (or in the case of WinFS will have) defined query mechanisms. In each case, the app dev will have to create a custom schema, will have to write custom code to query data based on that schema, and will have to write custom code to add/edit the data based on that custom schema.

    So far, in each case you have to do the same work writing the app. Perhaps deployment is easier? I don’t think so. I can copy an XML file, install an MSDE (and populate it), or add new schema to WinFS in probably about the same amount of installer code. Simply copying the XML file (or having the app create it on first use) would be easiest. In each case, you have to deal with ACLs for who can create, read, update, and delete from your file store. The XML might not require an admin to install. MSDE would. WinFS, I’m not sure on, but I’d think it would require admin install rights to add schema to the universal WinFS store (perhaps SEA makes allowances for this, so admin rights aren’t needed).

    Lastly, it seems that you minimize performance. There are apps I refuse to use, because they are too slow. MSDE and the current set of XML APIs are proven in terms of perf. WinFS, so far, is not. I think it’s rather risky to state how performant WinFS will be compared to existing technology until it has RTM’ed.

  2. Louis Parks says:

    Doh, that should be SEE not SEA.

  3. WinFS is based on the same but newer engine as MSDE, so assuming it will deliver a decent performance wouldn’t be too wrong.

  4. Shane King says:

    Anyone who thinks media player performance doesn’t matter doesn’t have enough mp3s. Winamp and iTunes perform pretty crap when you apply custom filters to large media libraries. I’d certainly trade off visualisations and skinning support for something quicker.

    As far as WinFS goes, I certainly wouldn’t want to differentiate my product as being something that will only run on the latest Microsoft OS. That kind of negative differentiation will be greater than any extra dev time for the non-WinFS solution for many years to come, I’d think.

  5. Louis Parks says:

    I’m not saying that WinFS will be slower than MSDE. I’m saying we don’t know how fast it will be. Arguably, System.XML is based on MSXML, yet MSXML is much faster than System.XML. Perhaps the same will be true of WinFS, that it will be based on Yukon, but that Yukon will be much faster. My point is that we don’t know yet.

  6. theCoach says:

    Louis,

    What about the synchronization and built in networking?

  7. Louis Parks says:

    What about them?

    MSDE support data synch. In fact, WinFS will support it, because MSDE (or more correctly the SQL Server engine) supports it.

    Built in networking? I have no idea what you mean by that. Still, WinFS is a db engine. It is based on SQL Server. It stands to reason that what ever "builtin" features WinFS has that it inherited from SQL Server an MSDE solution would already have. Again, no value add for using WinFS over MSDE.

  8. Louis Parks says:

    *MSDE Supports day sync.

  9. From what I could gather, the sync engine stacked on top of WinFS will be a completely different one than SQL Server replication/sync. I guess that includes the networking stuff theCoach means.

  10. Louis Parks says:

    Even so, since MSDE also has sync support, WinFS still isn’t a value add in this case.

  11. Anonymous says:

    Longhorn DevCenter Editor’s blog

  12. How did Microsoft attack Active Directory for clients before Windows 2000? There was an active directory client made specifically for those particular OSs.

    In hopefully the same fashion, there will be some kind of client that supports this use on the earlier versions of their OS. Will it be full WinFS? Probably not. Will it support the majority of its functions to allow your application to run on a previous OS? Hopefully so.

    Would this at LEAST be on every OS that is in Microsoft’s support range? That is what I would expect. Would it work on Windows 98? No and I say let it die anyways. Will it work on 2000 if 2000 is still supported by then? It should. Will it work on XP? I definately hope so because XP is supposedly the last version before Longhorn (unless the XP reloaded thing comes out which is a bad idea personally).

    Anyways if we were to take the track record of previous technologies as sound as this, we would begin to hope that Microsoft would make some kind of comperable system for the older clients. Will it be exactly WinFS? No but it would probably be very close. Microsoft would lose a lot of potential uses of WinFS by simply making it only available to Longhorn. There may be very good reasons why they keep it to just this platform but it wouldn’t make much sense for most of us.

  13. Jeremy says:

    Thanks all for the feedback. It’s always great to learn from people who know more than I do 😉 I didn’t know that MSDE supported SQL replication, I’m talking with the WinFS team to better understand the value WinFS Synch provides over SQL replication (change units in schema and a pluggable synch provider architecture are two that come to mind so far.)

    I’ll gather some more data and post an update soon, I hope. I’d love to get some data on the perf characteristics of storing a couple thousand records in an XML file vs. WinFS, but that will probably have to wait a bit longer.

  14. Of all the pillars of Longhorn, I’d have to say that I’ve read about Avalon the most. The reason for this is because I’ve really been interested in GUI design as of late, and that is exactly what Avalon is…

  15. phil says:

    If you want to understand the implications now of building such a replicated schema — build a Groove application. In fact, you don’t even have to build a Groove app as a number of the default tools provide wiki-like shared editing of a single document. What the Groove tool’s are missing are the wiki-isms for input.