littleguru said:

Parts of WinFS live on in other technologies. But the product itself has been cancelled.

It's interesting to see that once each half year we get a new thread that asks about where WinFS is.

Dovella said:

part of Win Fs is in Library of Windows 7 ?

Bas said:

Dovella said:

*snip*

I think part of the goals from WinFS eventually became Windows 7's Libraries, yeah. Doubt there's much of the actual code in there, but still.

DCMonkey said:

Bas said:

*snip*

Does anyone remember that Libraries were actually part of Vista in the post-reset CTP releases? I don't remember if they worked the same as the current implementation though.

Larry Osterman said:

DCMonkey said:

*snip*

As far as I know, Libraries are new for Win7. 

WinFS was essentially replaced by WDS.

I've yet to hear a compelling reason why WinFS would actually matter to any user (or most developers, for that matter).

• WinFS is a really brilliant idea and naturally makes sense because of the relational architecture.

Could you explain what exactly about WinFS you are missing?

It was an interesting prototype and lots of interesting technology came out of it, but it didn't even come close to being a practical replacement for the current data storage models prevalent on Windows.

• WinFS was essentially replaced by WDS.

That's sort of true, although as I recall, WinFS used the WDS indexer to provide its full-text search functionality

BHpaddock said:

• WinFS is a really brilliant idea and naturally makes sense because of the relational architecture.

Could you explain what exactly about WinFS you are missing?

It was an interesting prototype and lots of interesting technology came out of it, but it didn't even come close to being a practical replacement for the current data storage models prevalent on Windows.

• WinFS was essentially replaced by WDS.

That's sort of true, although as I recall, WinFS used the WDS indexer to provide its full-text search functionality

BHpaddock said:

• WinFS is a really brilliant idea and naturally makes sense because of the relational architecture.

Could you explain what exactly about WinFS you are missing?

It was an interesting prototype and lots of interesting technology came out of it, but it didn't even come close to being a practical replacement for the current data storage models prevalent on Windows.

• WinFS was essentially replaced by WDS.

That's sort of true, although as I recall, WinFS used the WDS indexer to provide its full-text search functionality

blowdart said:

BHpaddock said:

*snip*

The idea of objects.

Vista has the contacts folder; which is nice. If you're using Windows Mail. Use anything else and that folder stays empty. Now if there was a contact object in a file system everyone shared then that folder would be populated.

Now I realise when I type in a contact name WDS does pull it out eventually; but there's part of me that hankers after a common object store.

But boy was promoting objects to WinFS and back to the file system painful.

Larry Osterman said:

blowdart said:

*snip*

Who gets to define the schema for a "contact"?  How about a "document"?

Once you start thinking in those terms, you realize quite quickly that the idea of abstract "objects" can quickly become unworkable.  That's because Outlook's idea of what belongs in a contact object might be very different from Windows Mail's idea, which might be very different from Thunderbird's idea.

Here's a really simple example:  To Outlook, an email address is a multivalued string property which lists all the possible email addresses for a particular recipient (there could be a dozen or so of them depending on the topology of your network).  To Windows Mail, an email address would be just an SMPT address.  To the email system I wrote back in high school, it's a RSTS-E account name ([<octal value>,<octal value>], to something else, it might be something totally different, with a totally different syntax.

Now consider what happens when you use a contact in Outlook that was created by my high school email program?.  Outlook doesn't know how to send email to this contact, it doesn't even know how to interpret the address. 

Can you guarantee that all clients of this object store all handle these cases properly? 

This is just one small example of the kinds of interoperability problems you can get - this one is probably solvable, but there are others that aren't.

Larry Osterman said:

blowdart said:

*snip*

Who gets to define the schema for a "contact"?  How about a "document"?

Once you start thinking in those terms, you realize quite quickly that the idea of abstract "objects" can quickly become unworkable.  That's because Outlook's idea of what belongs in a contact object might be very different from Windows Mail's idea, which might be very different from Thunderbird's idea.

Here's a really simple example:  To Outlook, an email address is a multivalued string property which lists all the possible email addresses for a particular recipient (there could be a dozen or so of them depending on the topology of your network).  To Windows Mail, an email address would be just an SMPT address.  To the email system I wrote back in high school, it's a RSTS-E account name ([<octal value>,<octal value>], to something else, it might be something totally different, with a totally different syntax.

Now consider what happens when you use a contact in Outlook that was created by my high school email program?.  Outlook doesn't know how to send email to this contact, it doesn't even know how to interpret the address. 

Can you guarantee that all clients of this object store all handle these cases properly? 

This is just one small example of the kinds of interoperability problems you can get - this one is probably solvable, but there are others that aren't.

brian.shapiro said:

Larry Osterman said:

*snip*

I never looked too deeply into how WinFS was implemented, but one thing I took away from it was that meta-data would be self-described in XML. I'm interested in being able to attach any information I want to any file, using some format like Adobe's XMP, and have it readable in Explorer on any Windows computer. That would benefit me as an end-user just because it would allow me to catalogue and annotate my files. If different programs wanted to share information, I'd guess they would simply have to agree to some defined standard.

PaoloM said:

brian.shapiro said:

*snip*

Brian, the goal of universal and pervasive metadata is a worthy and noble one. The problem is how to support non-metadata aware formats (like TXT or GIF) and how to support moving files between diverse filesystems.

To solve the first issue, you could say that, for TXT, you could store extensible metadata in the index, but that means that information about that file is now not attached to the file anymore and a rebuild of the index would destroy all the metadata.

Regarding the second issue, attaching metadata to an NTFS alternate data stream would bind the data to the file, but it would be wiped out when moving the file to a non-NTFS system, like a CD/DVD or a OSX partition.

It's a really tough problem to be resolved while keeping in mind backwards compatibility and portability.

Larry Osterman said:

blowdart said:

*snip*

Who gets to define the schema for a "contact"?  How about a "document"?

Once you start thinking in those terms, you realize quite quickly that the idea of abstract "objects" can quickly become unworkable.  That's because Outlook's idea of what belongs in a contact object might be very different from Windows Mail's idea, which might be very different from Thunderbird's idea.

Here's a really simple example:  To Outlook, an email address is a multivalued string property which lists all the possible email addresses for a particular recipient (there could be a dozen or so of them depending on the topology of your network).  To Windows Mail, an email address would be just an SMPT address.  To the email system I wrote back in high school, it's a RSTS-E account name ([<octal value>,<octal value>], to something else, it might be something totally different, with a totally different syntax.

Now consider what happens when you use a contact in Outlook that was created by my high school email program?.  Outlook doesn't know how to send email to this contact, it doesn't even know how to interpret the address. 

Can you guarantee that all clients of this object store all handle these cases properly? 

This is just one small example of the kinds of interoperability problems you can get - this one is probably solvable, but there are others that aren't.

PaoloM said:

brian.shapiro said:

*snip*

Brian, the goal of universal and pervasive metadata is a worthy and noble one. The problem is how to support non-metadata aware formats (like TXT or GIF) and how to support moving files between diverse filesystems.

To solve the first issue, you could say that, for TXT, you could store extensible metadata in the index, but that means that information about that file is now not attached to the file anymore and a rebuild of the index would destroy all the metadata.

Regarding the second issue, attaching metadata to an NTFS alternate data stream would bind the data to the file, but it would be wiped out when moving the file to a non-NTFS system, like a CD/DVD or a OSX partition.

It's a really tough problem to be resolved while keeping in mind backwards compatibility and portability.

brian.shapiro said:

PaoloM said:

*snip*

I understand the problems involved, I just hope its something Microsoft is interested in working on

umerh said:

BHpaddock said:

*snip*

Well imagine, i had two calendar applications on my computer just because i liked the features offered by the two, lets say outlook syned with my exchange and sunbird helped me with some other problem ( i cant imagine what sunbird will help me with.... but lets assume it did).... imagine having how much will common store help you in this case!!! change made in one app will automatically reflect in the other.

Common data store can open up many possibilities for you as a user and certainly a lot for as a developer.

anyways, libraries doesnt really radically change the way we store data and relate the data in them and the ways apps interact with data.

i must admit that WinFS was really cool!!!

Larry Osterman said:

blowdart said:

*snip*

Who gets to define the schema for a "contact"?  How about a "document"?

Once you start thinking in those terms, you realize quite quickly that the idea of abstract "objects" can quickly become unworkable.  That's because Outlook's idea of what belongs in a contact object might be very different from Windows Mail's idea, which might be very different from Thunderbird's idea.

Here's a really simple example:  To Outlook, an email address is a multivalued string property which lists all the possible email addresses for a particular recipient (there could be a dozen or so of them depending on the topology of your network).  To Windows Mail, an email address would be just an SMPT address.  To the email system I wrote back in high school, it's a RSTS-E account name ([<octal value>,<octal value>], to something else, it might be something totally different, with a totally different syntax.

Now consider what happens when you use a contact in Outlook that was created by my high school email program?.  Outlook doesn't know how to send email to this contact, it doesn't even know how to interpret the address. 

Can you guarantee that all clients of this object store all handle these cases properly? 

This is just one small example of the kinds of interoperability problems you can get - this one is probably solvable, but there are others that aren't.

BHpaddock said:

umerh said:

*snip*

What's stopping Outlook and Sunbird from using a common format today?

Nothing.  Except the same thing that would stop them from using a common schema in WinFS.

blowdart said:

BHpaddock said:

*snip*

That's simple; there is no common format today. If the OS manufacturer doesn't set an example why should anyone else.

However if there had been a WinFS common object format, with scope for extensibility then you may well have seen it used.

Larry Osterman said:

blowdart said:

*snip*

Blowdart, I think that you're missing Brandons and my point.  There are three options to how to handle the schema:

1) MSFT defines a fixed schema (or a base schema).  3rd party vendors scream because the base schema doesn't meet their needs.
2) The first app installed defines the schema.  There is no interoperability because there is no standard for the schema.  [12,3] doesn't really work very well as an email address these days.
3) Each app extends the schema in their own way.  There is no interoperability because the applications don't share information.  Or worse, app A reads the info from app B and modifies it.  But app A doesn't understand that app B has actually tied two separate fields (the base field and an app B specific extension) and app A has just corrupted app B's view of the schema.

Marking apps as "WinFS aware" doesn't help, app A and app B are both WinFS aware.

Building an open extensible shared common object model is a nightmarishly hard problem, that's why (to my knowledge) nobody has built such a beast before.  The best that's been done is to define fixed export formats and people interchange data using those.  On the other hand, when there's a low fidelity mapping, you get things like winmail.dat.

I'm not saying that the problem can't be solved.  I suspect it could be.  But I'm saying that this problem is crazy hard.

Larry Osterman said:

blowdart said:

*snip*

Blowdart, I think that you're missing Brandons and my point.  There are three options to how to handle the schema:

1) MSFT defines a fixed schema (or a base schema).  3rd party vendors scream because the base schema doesn't meet their needs.
2) The first app installed defines the schema.  There is no interoperability because there is no standard for the schema.  [12,3] doesn't really work very well as an email address these days.
3) Each app extends the schema in their own way.  There is no interoperability because the applications don't share information.  Or worse, app A reads the info from app B and modifies it.  But app A doesn't understand that app B has actually tied two separate fields (the base field and an app B specific extension) and app A has just corrupted app B's view of the schema.

Marking apps as "WinFS aware" doesn't help, app A and app B are both WinFS aware.

Building an open extensible shared common object model is a nightmarishly hard problem, that's why (to my knowledge) nobody has built such a beast before.  The best that's been done is to define fixed export formats and people interchange data using those.  On the other hand, when there's a low fidelity mapping, you get things like winmail.dat.

I'm not saying that the problem can't be solved.  I suspect it could be.  But I'm saying that this problem is crazy hard.

blowdart said:

Larry Osterman said:

*snip*

Oh I'm not missing the point at all and I'm not saying its easy; but the problem is already solved with AD, to an extent. You can extend AD by adding attributes to existing classes, or add new classes; but the basic objects remain the same. You could even enforce a vendor naming convention for new attributes or classes in much the same way we have -moz in CSS.

That way you avoid (1) because vendors can extend the base classes to add their own functionality. You don't avoid (2) of course; but that can be brought under control by having the OS define the base classes; and open up the base class design to a community in much the same way the W3C is for HTML. But yes you can't stop (3) happening, unless you have conventions in place, in much the same way as meta directories do with LDAP and LDAP extensions, or how AD extensions work.

blowdart, you're sort-of right.  However there's a huge difference between the AD and WinFS.

The AD is centrally deployed and managed and where the only applications allowed to modify the AD schema are those that are deployed by the system administrators, who have presumably tested and ensured that all applications deployed interoperate fully.

WinFS was going to be deployed on desktop computers and any application installed by the end-user would presumably be allowed to modify the schema.  The end-user would have essentially no ability to verify the interoperability between applications.  And the vendors wouldn't necessarily either - there are a LOT of applications out there.

At the core, you're right: This could be solved with an extensible schema.  But IMHO it would turn into a freaking nightmare for the customers.  You know how some geeks hate the registry?  Let me tell you, every failing the registry has (and I don't think there are tat many of them, to be honest) would have been several orders of magnitude worse in WinFS.  Geeks would absolutely despise WinFS.

Larry Osterman said:

blowdart said:

*snip*

blowdart, you're sort-of right.  However there's a huge difference between the AD and WinFS.

The AD is centrally deployed and managed and where the only applications allowed to modify the AD schema are those that are deployed by the system administrators, who have presumably tested and ensured that all applications deployed interoperate fully.

WinFS was going to be deployed on desktop computers and any application installed by the end-user would presumably be allowed to modify the schema.  The end-user would have essentially no ability to verify the interoperability between applications.  And the vendors wouldn't necessarily either - there are a LOT of applications out there.

At the core, you're right: This could be solved with an extensible schema.  But IMHO it would turn into a freaking nightmare for the customers.  You know how some geeks hate the registry?  Let me tell you, every failing the registry has (and I don't think there are tat many of them, to be honest) would have been several orders of magnitude worse in WinFS.  Geeks would absolutely despise WinFS.