Shishir Mehrotra - WinFS beta 1 team meeting
- Posted: Aug 29, 2005 at 4:48PM
- 64 comments
Last week Shishir invited us over to have a chat with the WinFS team. Imagine our suprise when Quentin Clark, director of program management on the WinFS team, started the interview by handing interviewer Robert Scoble a CD with beta 1 on it.
We then spent an hour with the team getting up to date on what they've been doing. Also seen is Samuel Druker, development manager.
One thing that's real exciting? WinFS will be released on not just Windows Vista (the demos here are seen on Windows XP).
Sorry about the focus problems, our camera is starting to freak out.
There are already two threads started about the WinFS release today, by the way:
Looks like WinFS is back on track and
WinFS Beta 1 Released.
The demo starts at about 11:00. Don't miss that!
Comments closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.
More entries in this blog
-
Channel 9 Team - Welcome to our new design
-
Shishir Mehrotra - WinFS beta 1 team meeting
-
Iain McDonald - Talking about release candidate of…
Follow the discussion
Oops, something didn't work.
What does this mean?
Subscriptions allow us send you email notifications when new content is added. You need to be signed in to Channel 9 to use this feature.What does this mean?
Subscriptions allow us send you email notifications when new content is added.sign up for email notifications?
http://channel9.msdn.com/showforum.aspx?forumid=14 shows that this is the 522 video.
Better video quality = bigger bandwidth requirements. And then other Channel 9 users would be bitching about how long it takes to download, or how it won't stream smoothly over their connection. So it's a compromise.
To get best quality use the "Download" link. That's a 500kbps file. It's already more than 200MB. How much bigger do you want me to make these files? At some point someone will ask me why our videos are sucking up all available bandwidth coming out of Redmond.
If you are using the download file the quality is actually pretty good. What player/OS are you using?
This one was encoded at 320x240 at 500kbps. If I did it the way the Ballmer one was done it'd be 1GB instead of 200MB. Unfortunately there is a limit to what we can distribute out.
No problem, just provide a .torrent link. Makes more sense than an HTTP download. It's pretty slow as it is.
Movies play fine for me Scoble, keep up the good work, you're doing fine man.
those screen shots are impossible to read, we should think up some way around that - any ideas? And we can't get everyone to install camptasia can we? :O
Why the hell not??? That is half the fun.
The screenshots were hard to see, but the converstation was interesting enough and at least you can see some of the screen.
I have a new HDTV camcorder that I'm playing around with.
Maybe we could do stills of those parts of the video?
I hate not being able to communicate effectively either. I'll figure out some way to do this stuff better without making everyone download huge files and without making all my interviewees load software (which they aren't gonna do).
I like that idea
I watch HDTV only laptop. HDTV resolution isn't that high and it can be scaled.
Edit: anyway, I think he is just talking about video stills not entire movies...
I really don't have the time to download a 2-5Mbps (I am guestimating) stream of video.
I think like screenshots of the code instead of video's of the code.
Also, in response to your earlier posts about stream data: we have a metadata handling infrastructure that enables these kinds of things that you talk about. We don't provide decoders for every kind of metadata you could think of but a developer can build custom ones and add them to the system (similar to IFilters or IPropertyStores).
...so is that a no???
Question - Is the db engine a close relitive of lets say SQL2005 Express - If so can they both co-exist (different instances?)
Also - I assume that the relationale asspects of the tables will be accessable via SQL (not just OQL or whatever it is called). Meaing that we can technicly build our apps on top of winfs without having to install sql server 2005.
for one example; as i understand, even though avalon will be backported to xp, the desktop compositor, wgf, will still be only be working in longhorn, so avalon will work much better in longhorn. (someone tell me if i'm wrong).
also its obvious just all of the longhorn features through subsystems like avalon, indigo, and winfs, will be more directly available and usable by longhorn's new interface and new general api, which will be designed around them. so you get simple things like a breadcrumb bar in explorer.
the backporting is mainly for compatibility purposes and for developer purposes i think.
I would almost prefer one of those flash demos with audo overlay and direct-line video.
samdruk,
i would be interested to hear your response to what hans reiser said about win fs on slashdot:
http://it.slashdot.org/comments.pl?sid=160472&cid=13433454
He looks like a Quentin.
BA DUM PSHH!
I may be wrong here, (no doubt someone will correct me if I am) but I believe WinFS is a Virtual Object Store, that provides SQLD and filesystem services.
The difference?
- Queries return lists of typed objects (person, video, email), not virtual directory lists
- The built-in, extended, and added (new software install) data schemas have class reflections that are fully and dynamically integrated into the CLR/CLI of .NET
- <speculation>The filesystem layer is a legacy layer, future programs will not use WinFS to retrieve a win32 file handle, they will only manipulate the WinFS object (and any underlying data on disk) through one of its exposed interfaces. (stability/performance
tradoffs involved in this left to the imagination of the reader)</speculation>
So in a attributed filesystem like BeFS I can list a directory or run a query and get back a list of files and for each of these files I can then list and retrieve its attributes. One of these will be a type attribute, and from that and documentation I can expect certain other attributes to exist.Attributes of course can be indexed.
Attributes can be added.
In WinFS on the other hand I can list a store or run a query and get back a heterogenous list of objects. They will all have some common interfaces, but also the interfaces specific to their type, as documented.
Attributes of the objects can be (are? to what extent?) of course be indexed.
Interfaces and attributes can be added.
Which way is better? I don't know.
Is strong typing in programming languages always better or worse?
Is a simple class hierarchy (htmlDoc->getElementsByTagName("title")...) or a custom complex one (htmlDoc->html->head->title) better?
What is clear is that the WinFS approach fits in with the CLR/CLI and the Object Manipulating Shell (MSH/Monad)
First of all, you guys should be using 2-pass VBR instead of the crappy 1-pass CBR. I think you'll find the quality difference is pretty big
500kbits should give you a pretty detailed video at 320x240 res with 2-pass VBR. Try it out!
too bad where going to wait over two years to get the final product
The poor, average and privilage
Finally WinFS is released, never thought this would happen.
I have some questions that I would appreciate if someone could answer:
1) How and where are all the relations, keywords etc saved? I couldn´t get that into my head while watching the video.
2) How do the WinFS get all the mails and stuff? Do I have to copy every mail ino the WinFS Store? Sounds a little bit complicated..
3) Do I have to set all the relations manually? How does WinFS know which document is created by which user?
4) Do I have to create all profiles by my own, or are they created automatically when I get a document/mail/image/another file by someone?
5) Is it possible to share the profiles so if I update my own profile, everyone who uses it will get the latest information?
Thanks,
Mikael Söderström
It was great to see WinFS in action. Thanks for the video, C9!
IMHO, calling it a "file system" is really doing it a disservice even if ultimately becoming Windows' next file system is its most important near-term future goal.
Yes, I know its current incarnation is as a layer on top of NTFS, but in the future, that may not be the case. From the comments they made about WinFS in the video, they chose NTFS because it was easier to use a robust, mature file system like NTFS to build the "file system" bits of WinFS than to build a new one from scratch.
Likewise, SQL Server 2005 may not be the database engine that drives WinFS in the future; one of Hans Reiser's beefs about WinFS is that it uses a relational model, which he feels isn't appropriate for a filesystem. Personally, I think Reiser's right but for a different reason than he thinks. I'm less concerned about the suitability of the relational model for modeling filesystem data and more concerned about the "impedance mismatch" of object-oriented and relational database models, something that has been a thorn in the side of O/R and OODB models for a very long time. MS has a lot of very bright people in their employ; maybe they'll figure out something.
Anyway, as with NTFS, MS is using SQL Server 2005 because it was easier to use a robust, mature database like SQL Server than to build a new object-relational or object-oriented database from scratch. The flip side is that the next generations of WinFS will have to support legacy artifacts of having its first generation be an NTFS-based, SQL Server-based file system, but I guess they figured they'd rather cross that bridge when they get to it than to release something in the early-mid 2010's.
It'll be interesting to see what the open source guys come up with after WinFS comes out, though I wonder if they will be as hamstrung by their UNIX legacy as Microsoft is by their NT/SQL Server legacies. Reiser's comments about his file system's UNIX dependencies suggests that it will be hampered by that legacy... but not forever. What MS is trying to do with WinFS could be bigger and more powerful than UNIX, NT, and SQL Server.
Let's not forget Google, who's coming at this from their own angle (the power of search; the Internet as the filesystem).
The only thing I'd change is having some kind of "direct feed" from the screen, where you record both the live video of the guy + have another feed recording the VGA/DVI output from the demo machine. Keep it running through the entire presentation, then edit them together in an edit session...
hope that doesnt introduce TOO much extra work, but the benefits will be better because as you switch back and forth from Video to "Demo" or code sampling, the code video will be much better (and immune to the scoble caffeine hand twitching and zooming)
Anyways, this is awesome technology. I've been looking forward to WinFS info for a while, going so far as to try to model my current project types to mimic winfs types (Contact, Person, Org) and so forth.
One more thing: I'm trying to start testing and learning all the new stuff, but don't find a good point to get started. I mean, don't you have some example app, like pet shop or something, where I can start learning?
Better security. Better user interface. Better performance. More features. Better applications. Shall I go on? Let's talk after the PDC since a good percentage of Windows Vista will be discussed there.
It's possible, but not very probable. See, I'm getting access to teams where others aren't because I don't take much of their time. In fact, with Steve Ballmer I had only 10 minutes.
Every system at Microsoft is different, too, so getting it setup properly would be a real pain.
Also, my videos are very conversational and not very demo centric. Plus, I'm not doing much editing (I hate editing, to tell you the truth). Capturing the screen and then switching back and forth would require a lot of editing.
Also, even if I captured the screen, if I down sampled to 500kbps it'd still be blurry. In fact, it'd be far worse because most capturing tools only let you capture the whole screen and don't let you zoom in on the part of the screen (and the ones that do allow you to zoom require you to pay attention to their software, rather than to do an interview. It's hard enough to pay attention to a camera while trying to think about the next question you should ask.
The registry was first used to point to specific dll's, eventually people started storing application specific data in it. Which is when the problems started. IMO. Linux/Unix and OS X (I think, I 'm not sure about OS X) require your shared libs to be in the path. Which is a little easier (e.g. no real DLL hell) but you have to hope that an application you want to use was compiled against the version of the lib you have.
That being said, it's nice to have everything in your /home/~user dir. When I upgraded to OS X 10.4, I just zipped up my home dir and copied over to a network drive.
As someone who spent two days hunting down dependancy issues when trying to install the Ruby on Rails framework under Ubuntu Linux, I'd respectfully disagree with you on this point. A lot of time the archive file containing the source for a lib will contain a version # in it's name, but the binary ends up being called the same name as any other version and there isn't any easy way to determine which version you've got. If there is, tell me about it.
IMO, better security should never be a reason to PAY for an upgrade. I'm more interested in the other reasons, my security is fine. Hardware firewall, software firewall, A/V, A/S, etc...
When's PDC? Two more weeks? Three weeks? I'm not going, but it'll be interesting to see what you've been "anti-hyping" for months now.
I'd also like to see what comments samdruk has wrt Reiser's comments. I hadn't heard of Reiser before but I went to his site and boy does this guy know his stuff! I'd be great if MS could provide information about WinFS at the detailed level Reiser does for his filesystem.
Anyways, any comments in response to that slashdot post would be great!
I have posted up some prelims of my testing on my Blog, but thought there may be a need to contact them more directly. Since there are a couple different blogs, should we use the WinFS team blog for comments?
The Win32 file api is just a layer to a binary store (NTFS) too. My point isn't that layers can't be added to interoperate. My point is that MS is developing the WinFX/WinFS api and (I speculate) deprecating the Win32 file api. Are they right to? Will it work? Hell, I don't know. I used to think Hans Reiser was the best bet for improved FS semantics, and MS was spinning its wheels, now I'm not so sure.
The Win32 file api has a fixed schema for the objects its contains: Directory, File, Attributes. Further classification is value dependent, not type dependent.
BeFS was like this too. BDirectory, BFile, and a fixed set of attribute types (int, string, ...)
So to determine further classification BeOS had to provide a FileTypes service that told you that BFiles which had a TYPE attribute with value text/rfc822 had a Sender attribute of type string.
Mac OS seems to be going down the BeFS route (see Ars Technica), but with the UTI improvement.
ReiserFS too to some extent although the FS Plugins and the overall vision adds significantly more to the mix.
The WinFS api on the other hand looks to be designed to have a dynamic and discoverable schema. And the UI (GUI and CLI) will depend on that fact. Type information is provided in the same way as for any CLR object. Objects in the store can be manipulated like any other CLR object.
I think its fairly clear from the video that there will be some pretty important stuff in WinFS Stores that have no existence outside the database. Like Contact objects.
I can see the following being possible in Monad...
MSH C:\> new-drive -name Contacts -Provider WinFS -root "\\Computer\DefaultStore\Users\JoeBloggs\Contacts"
MSH C:\> set-location Contacts:\
MSH Contacts:\>get-childitem
Name Phone
------- --------
Jack 555 1234
Jill 555 5678
and in CMD...
C:\> net use E: \\Computer\DefaultStore\Users\JoeBloggs\Contacts
C:\> e:
E:\> dir /b
E:\Jack.mscontact
E:\Jill.mscontact
but if you tried to find Jack.mscontact on any Hard Disk, the closest you would come is something like C:\Users\JoeBloggs\DefaultStore.sql - The SQL Server Database containing Joe's Default Store.
On the other hand the Word 2000 document \\Computer\DefaultStore\Users\JoeBloggs\All Documents\Report.doc
also exists as C:\Users\JoeBloggs\Documents\Report.doc
But I think Microsoft sees that as the legacy case. They envision user files in the store only, with legacy access through the SMB interface.
Why do it? I might be wrong, but I think if you get rid of the NTFS write through you get rid of File/Save. And a lot of other FS stuff. I think they looked at what was on peoples disks and said, "There are more databases than hierarchies".
I think Hans Reiser is looking to improve the Unix File System while staying true to its "Everything Is A File" philosophy.
In contrast I think the guys developing WinFS are database guys. They didn't drink the EIAF kool aid. They are not building a database add on to NTFS, or an object layer over NTFS, or a search index, or the new improved windows file system. I think they are making an object database the heart of how user data is stored on windows systems. And it works well enough right now to stick up on MSDN.
We are not in Kansas anymore.
After all, SQL Server 2000 can already use raw partitions for storing databases and it's not that big a step from there to storing files directly in the database rather than externally on a file system.
Not exactly. There are two manners of accessing data in WinFS. One is via the Win32 CreateFile/OpenFile APIs (and their managed counterparts). These APIs allow you to double-click files within WinFS and have them open in Word, Photoshop, etc. However, this API only gives you what you get in Win32... file streams.
However, we have built a set of managed APIs that expose WinFS data as CLR objects with relationships, etc. This API is what the applications you saw (LifeJournal, StoreSpy) work against to create and navigate relationships.
In the WinFS world, how does that work? I love the idea of WinFS and the capabilities that it provides, but it sounds very "local". I don't want "local" data. When I download some photos off my camera, I don't want it to live only on the workstation I am sitting at. I want to see it on my Media Center; I want my wife's PC to see it, etc. Now, I understand that the data in WinFS is visible to the network as SMB, but SMB loses the "cool" part of WinFS--things are back to just being files.
I get the impression that there is some kind of Sync capabilites to keep multiple PCs synchronized, but that sounds like a klunky solution to the problem. I don't want copies of everything everywhere. Set asside the fact that it is probably not instantaneous synchronization. I don't want to have to put 1TB hard drives on all my PCs just so that they can all have local copies of my music, photos, documents, etc with the rich relationships intact.
I guess I'd like to see or hear that the richness of WinFS will be available in some model where the data "lives" on some server somewhere but where the richness, relationships, metadata are all available to clients that have WinFS (and not via a product that ships 3 years after "client" WinFS).
Am I dreaming?
http://download.microsoft.com/download/3/3/0/330bddc3-d61e-46f2-b0eb-1ff358a80027/new_winfs_returns_2005.wmv
How about providing two options? A Low- and a High Bandwidth download...?
I see this as "System Normalization", No repetative data....very nice, if devs will use the stores available, you can effectivly have one place to store contacts and 5 or more apps can use it, one changes it and the rest see it dynamicly......very nice...
Also how does this tie into LINQ?
The information of the files are stored in a relational database. We can explore and view it by many different format.
For example Blog is only an kind of template, event calendar is only a template, album is only a template and address book is only a template too. I did the same job on MSSQL before. It is only a small step to put it public viewable like a personal webpage. And I believe it can be as easy as to set the folder sharable in the future.
Remove this comment
Remove this thread
Close