Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

Larry Osterman Larry Osterman
  • windows 7 !=  MinWin

    ZippyV said:
    littleguru said:
    *snip*
    Because some dudette from MicrosoftWatch saw that presentation, wrote an article about it while inventing silly things that could be done with it. Other would-be journalists see this information as fact and make the wrong conclusions when they see Microsoft doesn't follow what MSWatch had invented.
    I'm not sure it was that simple, but in general, you're right.

    I've been fascinated by this whole "minwin" thing, to be honest.  All it's been was refactoring code along architectural layering lines, and it's the natural extension of what we've been doing since the Longhorn Reset (so arguably Vista was the first "minwin" based operating system).

  • What happened to WinFS...

    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.

  • What happened to 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.

    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.

  • What happened to WinFS...

    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.
    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.

  • Windows 7 error reports

    There should be a big "Give Feedback" button on the desktop, click it and you'll be able to give feedback to the team.

  • What happened to WinFS...

    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.

    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).