Abstract
This article focuses on how Longhorn core pillars like WinFS will change the way applications will be written. Using a Bug Tracker, as an example, it explores how Win FS enables capture and maintains relations of contextual metadata. This leads to a whole new class of applications that are built on metadata relationships. Start Thinking differently!
Disclaimer � Longhorn is a work in progress, so things will change. This is a conceptual article and explores how applications can be transformed using Longhorn technologies. I don't work for Microsoft and have never talked to the WinFS team, but I expect them to head in this direction. The screenshots are concept shots and are not possible to build with the current SDK since WinFS does not support custom schemas. The ideas in this article originated with my vision for Context based communication.
This article is not about selling Longhorn and WinFS, and I don't expect you to start programming for a platform that does not have any ship date. The main intention of this article is to explore what the value of standardized metadata storage and relationships bring to the table. I expect that there are and will be other technologies offering the same capabilities of Metadata storage and relationship management.
Introduction
Longhorn with its different pillars brings about fundamental philosophical changes to the way applications will be designed. An example of a fundamental change is WinFS. Storing your data in an object relation store enables you to describe the relationships between data objects. These relationships are not only useful to your application but also to other applications that can reuse the same data and their corresponding relationship.
For example, using one common Contact data store in Longhorn lets different applications access the same data. If I save a contact in Outlook Express or Outlook, it is available to my cell phone because the phone is synced to the Contact store.
Context based communication
Every Communication that occurs has some metadata or context associated with it. When you ask someone - Is the API bug fixed? Unless the context of what API bug is established, the other person will have no idea what you are talking about. Most of the time, context is established transparently and this information is never captured and reused.
A reason for this is most of the communication happens outside of the application. For example, an important conversation on how to fix a bug may happen over email and is never captured by the bug tracking system at all. The next developer who is fixing a similar bug has to start all over again.
Context based communication systems help you transparently capture context metadata and use it. If I am viewing a bug, I should be able to click on the person and start a conversation that would also be logged by the bug tracker. The next developer with a similar bug would be able to access and use information in our conversation.
Looking at my Contacts, I should also be able to see other details like number of open bugs, fixed bugs etc. What I want is a bird eye view into a person, where the information is aggregated from various applications.
Islands of information
Information loss also occurs because each application stores information in its own private space. For example, Outlook knows that Jill Doe�s IM ID is jdoe@hotmail.com but my Bug Tracker cannot use this information unless I enter it manually.
Information is scattered among different applications and there is no concept of sharing information in a way that is usable. One of the primary reasons for information loss is that information is stored in different places by different applications using different schemas and file formats.
Storing information in XML does not solve this problem as there are no standardized XML data stores and schemas defined.
What do we need
We need a way for data to be shared between applications and also for maintaining relationships between data. WinFS is designed to make things like this possible.
Instead of a private application store of contacts, WinFS enables you to store data that can be read by an application. This enables two different applications to share the same information.
Because WinFS is an object relational store, it also can maintain relationships of the different data that it stores. For example, it can associate a bug with a person in its Contact store and the list of comments tied to a bug.
It�s all about relationships. You need to be able to have well defined entities and defined relationship between entities.
How is this different
In a normal application, you store data about users, application settings, application data, history and logs in a proprietary format or in a SQL database.
What make this different are three things:
- Data is shared
- Data schemas are defined
- Data relationships are defined
This is a big step forward and it�s equivalent to the move to event driven programming under Windows. Opening and sharing your data is a scary process and every application will have to decide how much to share. Some applications may decide not to share data, as it is a competitive advantage.
How can we make a bug tracker using longhorn
There are two ways to build a better bug tracker. Look at your current bug tracker and figure out what Longhorn technologies to integrate it with, or build a new user model using Longhorn as a base. This article focuses on a conceptual model on how a new bug tracking application could be designed.
Longhorn enabled Bug Tracker
A Longhorn designed Bug Tracker would make use of the following features:
- WinFS
- Contacts Store
- Tasks Store
- Communication History Store
- Notification and Alert System
- Avalon
- Longhorn shell
Contacts Integration
In the above picture, I can see the projects that Aaron is working on, fixed, open bugs, and other information from the Bug Tracker system. Clicking on the open bugs, I can see more details on them. Also, the Longhorn shell tracks Aaron�s presence.
The result is a 360 view on Aaron�s professional relationship with me.
Communication History
Integration with the Communication History allows me to view bugs history. Any communication that happens around the context of the bug is captured and displayed in the Communication History windows and is also stored by the bug tracking application.
Notification and Alerts
Notifications allow me to get a quick update on the bugs that need my attention. Longhorn�s Notification system allows me to deal with Notification without filling up my Email Inbox.
Bug Stacks
Bugs can be seen as stacks in WinFS folders. In the above example, Jason Carlson has 9 open bugs.
Avalon Screens
This is a sample issue entry screen that is build using XAML. The Assigned To combo box picks up Contacts from the WinFS Contact store.
Task View
Bugs to be assigned to me would appear in the Task View and my interactions with these tasks would be sent back to the bug tracking application.
What does my application do (if Longhorn is doing most of the work)
Good question. Let�s look to history for an answer. In the DOS days, DOS applications like Word Perfect shipped multiple floppy disks containing video and printer drivers. Under Windows, applications turned over ownership of the display and printer to Windows and never had to ship a single video or printer driver. Software has a way to fill up the entire space it occupies, so I am sure there will be new features that customers will demand.
Conclusion
Using WinFS to its full extent, means that you give up the 100% control you had on data your application uses. But it also means deep integration with the Shell, and allows information to be manipulated in various different ways by the end user. Using relationships and data schemas, Longhorn allows context to be captured and reused across applications. Information that was hidden earlier can now be used in ways that were not possible before. The question is � will you open up your data?
