Linked by Thom Holwerda on Sun 11th Mar 2012 22:21 UTC
Windows And thus, Microsoft bites itself in its behind with Metro. As you all surely know by now, the Metro environment in Windows 8, and its accompanying applications, need to follow a relatively strict set of rules and regulations, much like, say, applications on iOS. For one type of application, Metro has already proven to be too restrictive and limited: web browsers. Microsoft has had to define a separate application class [.docx] - aside from Metro and desktop applications - just to make third party web browsers possible for Windows 8.
Thread beginning with comment 510284
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: I think
by Alfman on Mon 12th Mar 2012 06:14 UTC in reply to "RE[4]: I think"
Alfman
Member since:
2011-01-28

Nelson,

Can you point to *specific* code examples so that we might talk meaningful comparisons? I'm not going to believe the new APIs are better just because microsoft claims so; they've gone down this path countless times already. So why exactly are the new incompatible APIs better?

I'm not trying to make an assertion myself, but it seems some of the claims being made here warrant stronger evidence than has been given. Event oriented app models all tend to be reimplementing more of the same ideas, I'm curious to know if there's anything substantially different this time? What's been gained by creating yet another API?

Edited 2012-03-12 06:15 UTC

Reply Parent Score: 6

RE[6]: I think
by moondevil on Mon 12th Mar 2012 08:44 in reply to "RE[5]: I think"
moondevil Member since:
2005-07-08

Nelson,

Can you point to *specific* code examples so that we might talk meaningful comparisons? I'm not going to believe the new APIs are better just because microsoft claims so; they've gone down this path countless times already. So why exactly are the new incompatible APIs better?


Like any other company, even on FLOSS world, the new APIs are always better.

Just look for the sound APIs in Linux or QT APIs in MacOS X, just to cite two examples.

Reply Parent Score: 3

RE[6]: I think
by Nelson on Mon 12th Mar 2012 12:53 in reply to "RE[5]: I think"
Nelson Member since:
2005-11-29


Can you point to *specific* code examples so that we might talk meaningful comparisons? I'm not going to believe the new APIs are better just because microsoft claims so;


No of course not, the consumer preview is like a week old. I don't have two sets of code reimplementing the same functionality to link to you.

However, the facts speak for themselves. It's a fact that the legacy code is not mobile aware, and doesn't give you the breadth of information that the new networking model gives you.

Chief examples, like I stated before, being mobile broadband cost and cap awareness, and detailed information on network status switches. For instance, being able to know when a user switches from a metered 3G/4G connection to an unmetered WiFi connection is invaluable if you're trying to be resource conscious.

Another point, which I've made before, is that you're able to intelligently run these networking requests in the background (Through running as a Lock Screen App or by using Background Transfers.) . This is something that's not possible with vanilla sockets.


they've gone down this path countless times already. So why exactly are the new incompatible APIs better?


By countless you mean how many times exactly? .NET had two paradigms, the second of which mostly carries over into WinRT, except it's made optionally simpler by the async keyword.

As for native constructs like io-cp, these are a level above them, so not really comparable. They're just convenient, and coincidentally, the only way forward for Metro Style applications.

Even then, another advantage is the capability isolation. You get what you ask for. So users immediately know what type of network requests on which protocols the application will ever make.


I'm not trying to make an assertion myself, but it seems some of the claims being made here warrant stronger evidence than has been given.


I'm unsure how any of what I said above is not something immediately obvious. It's a given the old technology doesn't, or most likely can't, implement the new technology features. I then go on to cite said features as reasons for implementing the new technology. It seems pretty cut and dry to me.

Developers make the conscious choice, and I think this frankenstein hack let's Firefox developers have more leg room than I think they should be afforded.


Event oriented app models all tend to be reimplementing more of the same ideas, I'm curious to know if there's anything substantially different this time? What's been gained by creating yet another API?


I'm not sure what you mean by event oriented? Do you mean asynchronous? I have a feeling you're hinting at something here, and I'd be interested in discussing it further.

Reply Parent Score: 2

RE[7]: I think
by Alfman on Mon 12th Mar 2012 23:51 in reply to "RE[6]: I think"
Alfman Member since:
2011-01-28

Nelson,

"No of course not, the consumer preview is like a week old. I don't have two sets of code reimplementing the same functionality to link to you."

"However, the facts speak for themselves. It's a fact that the legacy code is not mobile aware, and doesn't give you the breadth of information that the new networking model gives you."

"I'm unsure how any of what I said above is not something immediately obvious. It's a given the old technology doesn't, or most likely can't, implement the new technology features. I then go on to cite said features as reasons for implementing the new technology. It seems pretty cut and dry to me."

I'll give you the benefit of the doubt that you know something your not saying which allows you to say these things. However I was hoping for more solid evidence than "immediately obvious" and "facts speak for themselves", since those are rather empty statements.

You say the networking has mobile cap awareness, but what exactly will apps do that they could not have done in a compatible way with older APIs? Is there really any technical reason that we'd fundamentally have to rewrite our whole application around a new API in order to take advantage of mobile cap awareness? I doubt it very much. I imagine the APIs have more in common than differences, which is why I would have liked to see an explicit concrete counter-example.

Reply Parent Score: 4