Click here to Skip to main content
Click here to Skip to main content

How Longhorn Transforms Applications

, 2 Jul 2004
Rate this:
Please Sign up or sign in to vote.
See how Longhorn core pillars like WinFS changes the way applications are written, based on metadata relationships.

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?

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Ashvil DCosta
Web Developer
United States United States

I am a software craftsman and have documented a small subset of my experiences that I hope that you will find it useful.

If you are starting a Software Development center, then you will find my presentation on Outsourcing Software Product Development very useful. This presentation is based on my experiences of co-founding and managing i3Connect.


Comments and Discussions

 
GeneralAn amusing disclaimer PinprotectorMarc Clifton3-Jul-04 14:34 
GeneralRe: An amusing disclaimer PinmemberAshvil DCosta3-Jul-04 16:42 
GeneralRe: An amusing disclaimer Pinmemberjmw5-Jul-04 4:52 
Generalmany pics don't work Pinmemberpeterchen3-Jul-04 7:58 
GeneralRe: many pics don't work PinmemberAshvil DCosta3-Jul-04 16:34 
GeneralRe: many pics don't work Pinmembergarythom_usa3-Jul-04 23:55 
Ashvil DCosta wrote:
It is fixed now.
 
Still broken, 2nd image from the top not showing for me.Cry | :((
GeneralRe: many pics don't work PinmemberAshvil DCosta4-Jul-04 15:44 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.140709.1 | Last Updated 3 Jul 2004
Article Copyright 2004 by Ashvil DCosta
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid