Inside MobileMe: Web 3 and Web client-server apps
MobileMe isn't just for iPhone users. It also expands upon the simple web apps delivered as part of .Mac using a cohesive Mac OS X inspired interface that behaves more like a desktop app than a web page, providing easy access to data from anywhere you have Internet access. Here's a look at how web apps have developed, how Apple's new online apps work, and the future potential of MobileMe's tightly integrated mobile, web, and desktop apps.
Inside MobileMe series segments
Inside MobileMe: Secrets of the Cloud and Mobile Push (Friday)
Inside MobileMe: Mac and PC cloud sync and mobile push (Saturday)
Inside MobileMe: Apple's Push vs Exchange, BlackBerry, Google (Monday)
Inside MobileMe: iPhone Mail (Tuesday)
Inside MobileMe: iPhone's Exchange alternative for contacts and calendarÂ*(Wednesday)
Inside MobileMe: Web 3 and Web Client-Server Apps (Today)
Before Web Apps: The Document Driven Web
In the era before web apps, the web was a relatively simple system of hyperlinked documents written in HTML. Click a link on a page and your browser would load a new page based on the referenced URL address. The web was brilliantly simple.
However, that simplicity resulted in a number of problems if you wanted to do more than just look at a series of hyper-connected documents. In order to exchange sophisticated transactions with a simple 'fill in the blanks on a form page and submit it,' you'd end up having to reload virtual pages repeatedly.
This is particularly problematic for something like web mail, where the user waits for updates while interactively sending new messages. Just over a decade ago, the concept of web email was entirely new. Unlike an actual desktop email application, handling email over the web meant loading a new web page, entering your email content, and reloading the page every time you wanted to see updates.
Web 2.0: the arrival of Ajax
In the mid 90s, Microsoft helped to pioneer technologies to improve upon the tedious loading of a series of web pages to do transactional web applications. The company was particularly interested in enhancing web-based email, as it was working to develop both its new mail server (Exchange) and its web browser (Internet Explorer) as critical elements of its overall Internet strategy.
The company first developed IFrames for allowing one page to be embedded in another (like picture-in-picture on TV), so the IFrame region could be independently refreshed and redrawn without reloading the entire page.
It later developed XMLHttpRequest, a method for using a web browser scripting language (often JavaScript) to package up XML data to send to the remote web server. The server then responds with new data which the script can use to interactively update part of the page, rather than reloading and redrawing an entire new page from the server. Because the user does not have to wait for the server to respond before continuing to use the web page, this type of interactivity is referred to as Asynchronous JavaScript with XML, or AJAX.
Microsoft introduced this concept to support richer functionality in Outlook Web Access, a web app it first bundled with Exchange Server 2000. It delivered Ajax functionally via an ActiveX control in IE 5; since then, the mechanism has been copied by Mozilla, Safari, Opera, and most other web browsers, making it a de facto standard for adding richer desktop-like behavior to web apps.
Web 3: HTML5 and Web Client-Server
While Ajax's frequent server updates provide richer interactivity than static web pages, they are rarely capable of being used offline and have other limitations that marginalize them in the minds of many users, who commonly view web email as being a distant runner-up to using a desktop email client. To work around these limitations, Microsoft's own OWA makes heavy use of proprietary extensions to Internet Explorer; few of these have been cloned in Firefox or Safari, nor can they really be because they are not documented standards. That leaves many OWA features tied exclusively to the IE browser; in other browsers it presents a simpler interface.
To foster real interoperability among the next generation of rich web applications, Apple, Microsoft, Mozilla, and Opera have been working on a new HTML5 standard that codifies how features should work so that all browsers can operate the same, and so web developers can make use of more sophisticated interactions on the web, knowing how their apps will behave across all browsers.
There are already web standards in place to define presentation, such as CSS; HTML5 focuses more on behavior, targeting features such as drag and drop, offline editing, local storage, and media playback. Just as Microsoft was motivated to rapidly develop Ajax in the 90s in order to enhance its email presentation on the web, Apple is leading the development of HTML5 to put its rich media client apps on the web, starting with the iLife-connected Web Gallery in .Mac, and broadening to the suite of apps in MobileMe, which will continue to develop in the coming months.
JSON Lives
Apple is building its MobileMe "Web Client-Server" apps using the SproutCore JavaScript application framework, which was designed around the concept of making web apps that are more than just a thin layer of Ajax lubricating interactivity on the web. A Web Client-Server app is loaded by the browser's JavaScript interpreter and runs as a self-contained application, making Ajax-like calls to the server while offering an even richer and deeper level of local user interaction, delivering a more immediate response to the user and offering the potential for client-side storage and offline operation.
Web Client-Server apps are entirely HTML pages driven by JavaScript code and presented via CSS. Rather than using the relatively heavyweight XML, they typically use JSON (JavaScript Object Notation), a lighter, simpler object representation that not only carries a data payload like XML, but is also executable by the JavaScript interpreter. This makes JSON faster in both data exchange with the server and in processing on the client side compared to XML.
With that power comes accountability. Being able to inject executable code into a system from malicious sources is a primary security problem. For that reason, web apps that transmit data using JSON have to authenticate with the server and regularly perform security handshakes to ensure that the data being sent back and forth is indeed coming from and going to a trusted source.
On page 2 of 2: What No SSL?; The emerging new platform for web apps; Apple's MobileMe web apps; and You get what you pay for.
What No SSL?
Data transaction security in MobileMe's web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple's cloud, rather than the SSL web page encryption used by HTTPS. The only real web pages MobileMe exchanges with the server are the HTML, JavaScript, and CSS files that make up the application, which have no need for SSL encryption following the initial user authentication. This has caused some unnecessary panic among web users who have equated their browser's SSL lock icon with web security. And of course, Internet email is not a secured medium anyway once it leaves your server.
If Apple applied SSL encryption in the browser, it would only slow down every data exchange without really improving providing perfect security, and instead present what could be a false sense of security that distracts from real security threats.
One other advantage held by MobileMe in terms of security is that Apple runs the entire show. There's no third party ads being injected into Apple's MobileMe apps, no external scripts introducing search results, alerts, or buddy lists that could potentially intercept secure transactions with the server, nor any opportunities for Adobe Flash, Microsoft's Silverlight, or other potentially vulnerable plugins to expose unforeseen security threats. A simplified trust relationship equates to stronger security.
The emerging new platform for web apps
While Safari, Firefox, and Internet Explorer all make different levels of attempts to follow the existing standards for HTML 4 and CSS, Safari and Firefox have done a better job of pushing web standards because it is in their interest to differentiate their browsers as being standards compliant. Microsoft could continue to push its own proprietary non-interoperability for another half-decade due to its closed ecosystem of developers who readily support using non-interoperable technologies because they have no need for them. That currently leaves IE 7 incompatible with some of the features in MobileMe (and IE 6 completely unsupported), but the good news is that Microsoft is working to adopt more of the W3C standards in the future.
Neither Safari nor Firefox are HTML5 compliant yet because the standard isn't yet even finished. However, both are already adopting some of its upcoming features in advance, as well as making enhancements to their JavaScript interpreters that will allow the next generation of web apps to run much faster. Apple's JavaScript interpreter is getting a lot of attention within the company, and has resulted in the fast new SquirrelFish for Safari 4.
MobileMe's web apps are therefore pioneering a new road just as Microsoft's OWA did nearly a decade ago with Ajax. The sophistication of MobileMe's apps should also have in impact on what browser users choose to adopt, as how well the browser follows standards and how quickly it can run JavaScript will have a major impact on how fast modern web apps will run. Microsoft has recently become distracted with Silverlight, which attempts to follow the course of Adobe Flash in loading an entirely proprietary level of middleware into the browser that is run by an external plugin. Microsoft also continues to use Flash, as it does in its new Mojave Experiment.
Apple's MobileMe web apps
If MobileMe can demonstrate that web applications don't require external plugins like Flash or Silverlight to function, it will have the opportunity to develop MobileMe into a platform and marketplace for online apps, just as the Apps Store opened the iPhone and iPod touch to third party developers. Apple typically develops its platforms internally first (as it did with iTunes, iLife, the iPhone, and .Mac sync), then exposes its private work as a public API third parties can use in their own apps.
The MobileMe service already supports a public API for syncing data and settings up to the cloud; this was originally part of .Mac, too. Apps can also copy up data to MobileMe's WebDAV hosted web server, as Delicious Library 2 does. While third party iPhone apps and external web services can already access that publicly published data, there is a tremendous potential for external new APIs that allow interacting with data stored in the MobileMe cloud, allowing iPhone apps to automatically sync settings or data with their desktop equivalents.
There is also vast, uncharted potential for Apple to host web apps developed by third parties that are either bundled into the MobileMe service, or sold as separate subscription service options. Opening up a viable and profitable market for online apps that share the same standards-based Web 3 platform would enable developers to copy Apple's desktop, web, and mobile integration. For example, Quicken could build an iPhone expenses app that synced with a MobileMe finances web app and its desktop equivalent.
The web app platform isn't complete; in fact, it's barely finished. Apple's MobileMe web apps aren't flawless, nor do the deliver feature parity with the company's established desktop apps that have seen nearly a decade of refinement. There's currently very limited support for offline operation; unplug from the Internet and there isn't much you can do. However, the pieces are all there and Apple can rapidly update its online apps to present new features immediately, without having to deliver new client software updates to every user. That's one of the most obvious advantages of web apps, in addition to being able to run nearly anywhere.
You get what you pay for
One of the biggest problems currently holding back the development of new web apps is the lack of a viable business model. It's hard to get users to pay for web services now that the web has become regarded as an entirely free medium. However, Apple has already found millions of paying subscribers for .Mac (including long time vocal critic Paul Thurrott), and will be selling MobileMe to millions of new iPhone users. Nobody else has figured out to sell subscription web services to millions of consumers as Apple has been, but Google, Microsoft, and Yahoo would love to do so.
Those ready customers will happily pay for the ability to connect their mobile to new custom web services and desktop applications. Further, Apple's hardware focus makes it the ideal merchandizer for web app developers; the company can deliver low priced deployment and billing services for developers with the intent of selling more iPhones and Macs rather than demanding huge overhead from developers, just as it has promoted its low priced, high volume iPhone Apps Store.
Security is another problem for web apps, as some sort of centralized authentication system is required to begin any type of secured transactions. Rather than each developer rolling their own security and authentication system, they could share MobileMe's. The presence of a centrally-secured market will result in rapid development of sophisticated new standards-based web applications. Safari's focus on developing advanced and fast JavaScript support will make it the ideal browser to use in rendering those applications on both the Mac and Windows PCs.
So where do Apple's MobileMe apps stand right now? The next Inside MobileMe segment will look at Apple's implementation of web email, how it compares with existing products, and where it needs improvement.
Inside MobileMe series segments
Inside MobileMe: Secrets of the Cloud and Mobile Push (Friday)
Inside MobileMe: Mac and PC cloud sync and mobile push (Saturday)
Inside MobileMe: Apple's Push vs Exchange, BlackBerry, Google (Monday)
Inside MobileMe: iPhone Mail (Tuesday)
Inside MobileMe: iPhone's Exchange alternative for contacts and calendarÂ*(Wednesday)
Inside MobileMe: Web 3 and Web Client-Server Apps (Today)
Before Web Apps: The Document Driven Web
In the era before web apps, the web was a relatively simple system of hyperlinked documents written in HTML. Click a link on a page and your browser would load a new page based on the referenced URL address. The web was brilliantly simple.
However, that simplicity resulted in a number of problems if you wanted to do more than just look at a series of hyper-connected documents. In order to exchange sophisticated transactions with a simple 'fill in the blanks on a form page and submit it,' you'd end up having to reload virtual pages repeatedly.
This is particularly problematic for something like web mail, where the user waits for updates while interactively sending new messages. Just over a decade ago, the concept of web email was entirely new. Unlike an actual desktop email application, handling email over the web meant loading a new web page, entering your email content, and reloading the page every time you wanted to see updates.
Web 2.0: the arrival of Ajax
In the mid 90s, Microsoft helped to pioneer technologies to improve upon the tedious loading of a series of web pages to do transactional web applications. The company was particularly interested in enhancing web-based email, as it was working to develop both its new mail server (Exchange) and its web browser (Internet Explorer) as critical elements of its overall Internet strategy.
The company first developed IFrames for allowing one page to be embedded in another (like picture-in-picture on TV), so the IFrame region could be independently refreshed and redrawn without reloading the entire page.
It later developed XMLHttpRequest, a method for using a web browser scripting language (often JavaScript) to package up XML data to send to the remote web server. The server then responds with new data which the script can use to interactively update part of the page, rather than reloading and redrawing an entire new page from the server. Because the user does not have to wait for the server to respond before continuing to use the web page, this type of interactivity is referred to as Asynchronous JavaScript with XML, or AJAX.
Microsoft introduced this concept to support richer functionality in Outlook Web Access, a web app it first bundled with Exchange Server 2000. It delivered Ajax functionally via an ActiveX control in IE 5; since then, the mechanism has been copied by Mozilla, Safari, Opera, and most other web browsers, making it a de facto standard for adding richer desktop-like behavior to web apps.
Web 3: HTML5 and Web Client-Server
While Ajax's frequent server updates provide richer interactivity than static web pages, they are rarely capable of being used offline and have other limitations that marginalize them in the minds of many users, who commonly view web email as being a distant runner-up to using a desktop email client. To work around these limitations, Microsoft's own OWA makes heavy use of proprietary extensions to Internet Explorer; few of these have been cloned in Firefox or Safari, nor can they really be because they are not documented standards. That leaves many OWA features tied exclusively to the IE browser; in other browsers it presents a simpler interface.
To foster real interoperability among the next generation of rich web applications, Apple, Microsoft, Mozilla, and Opera have been working on a new HTML5 standard that codifies how features should work so that all browsers can operate the same, and so web developers can make use of more sophisticated interactions on the web, knowing how their apps will behave across all browsers.
There are already web standards in place to define presentation, such as CSS; HTML5 focuses more on behavior, targeting features such as drag and drop, offline editing, local storage, and media playback. Just as Microsoft was motivated to rapidly develop Ajax in the 90s in order to enhance its email presentation on the web, Apple is leading the development of HTML5 to put its rich media client apps on the web, starting with the iLife-connected Web Gallery in .Mac, and broadening to the suite of apps in MobileMe, which will continue to develop in the coming months.
JSON Lives
Apple is building its MobileMe "Web Client-Server" apps using the SproutCore JavaScript application framework, which was designed around the concept of making web apps that are more than just a thin layer of Ajax lubricating interactivity on the web. A Web Client-Server app is loaded by the browser's JavaScript interpreter and runs as a self-contained application, making Ajax-like calls to the server while offering an even richer and deeper level of local user interaction, delivering a more immediate response to the user and offering the potential for client-side storage and offline operation.
Web Client-Server apps are entirely HTML pages driven by JavaScript code and presented via CSS. Rather than using the relatively heavyweight XML, they typically use JSON (JavaScript Object Notation), a lighter, simpler object representation that not only carries a data payload like XML, but is also executable by the JavaScript interpreter. This makes JSON faster in both data exchange with the server and in processing on the client side compared to XML.
With that power comes accountability. Being able to inject executable code into a system from malicious sources is a primary security problem. For that reason, web apps that transmit data using JSON have to authenticate with the server and regularly perform security handshakes to ensure that the data being sent back and forth is indeed coming from and going to a trusted source.
On page 2 of 2: What No SSL?; The emerging new platform for web apps; Apple's MobileMe web apps; and You get what you pay for.
What No SSL?
Data transaction security in MobileMe's web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple's cloud, rather than the SSL web page encryption used by HTTPS. The only real web pages MobileMe exchanges with the server are the HTML, JavaScript, and CSS files that make up the application, which have no need for SSL encryption following the initial user authentication. This has caused some unnecessary panic among web users who have equated their browser's SSL lock icon with web security. And of course, Internet email is not a secured medium anyway once it leaves your server.
If Apple applied SSL encryption in the browser, it would only slow down every data exchange without really improving providing perfect security, and instead present what could be a false sense of security that distracts from real security threats.
One other advantage held by MobileMe in terms of security is that Apple runs the entire show. There's no third party ads being injected into Apple's MobileMe apps, no external scripts introducing search results, alerts, or buddy lists that could potentially intercept secure transactions with the server, nor any opportunities for Adobe Flash, Microsoft's Silverlight, or other potentially vulnerable plugins to expose unforeseen security threats. A simplified trust relationship equates to stronger security.
The emerging new platform for web apps
While Safari, Firefox, and Internet Explorer all make different levels of attempts to follow the existing standards for HTML 4 and CSS, Safari and Firefox have done a better job of pushing web standards because it is in their interest to differentiate their browsers as being standards compliant. Microsoft could continue to push its own proprietary non-interoperability for another half-decade due to its closed ecosystem of developers who readily support using non-interoperable technologies because they have no need for them. That currently leaves IE 7 incompatible with some of the features in MobileMe (and IE 6 completely unsupported), but the good news is that Microsoft is working to adopt more of the W3C standards in the future.
Neither Safari nor Firefox are HTML5 compliant yet because the standard isn't yet even finished. However, both are already adopting some of its upcoming features in advance, as well as making enhancements to their JavaScript interpreters that will allow the next generation of web apps to run much faster. Apple's JavaScript interpreter is getting a lot of attention within the company, and has resulted in the fast new SquirrelFish for Safari 4.
MobileMe's web apps are therefore pioneering a new road just as Microsoft's OWA did nearly a decade ago with Ajax. The sophistication of MobileMe's apps should also have in impact on what browser users choose to adopt, as how well the browser follows standards and how quickly it can run JavaScript will have a major impact on how fast modern web apps will run. Microsoft has recently become distracted with Silverlight, which attempts to follow the course of Adobe Flash in loading an entirely proprietary level of middleware into the browser that is run by an external plugin. Microsoft also continues to use Flash, as it does in its new Mojave Experiment.
Apple's MobileMe web apps
If MobileMe can demonstrate that web applications don't require external plugins like Flash or Silverlight to function, it will have the opportunity to develop MobileMe into a platform and marketplace for online apps, just as the Apps Store opened the iPhone and iPod touch to third party developers. Apple typically develops its platforms internally first (as it did with iTunes, iLife, the iPhone, and .Mac sync), then exposes its private work as a public API third parties can use in their own apps.
The MobileMe service already supports a public API for syncing data and settings up to the cloud; this was originally part of .Mac, too. Apps can also copy up data to MobileMe's WebDAV hosted web server, as Delicious Library 2 does. While third party iPhone apps and external web services can already access that publicly published data, there is a tremendous potential for external new APIs that allow interacting with data stored in the MobileMe cloud, allowing iPhone apps to automatically sync settings or data with their desktop equivalents.
There is also vast, uncharted potential for Apple to host web apps developed by third parties that are either bundled into the MobileMe service, or sold as separate subscription service options. Opening up a viable and profitable market for online apps that share the same standards-based Web 3 platform would enable developers to copy Apple's desktop, web, and mobile integration. For example, Quicken could build an iPhone expenses app that synced with a MobileMe finances web app and its desktop equivalent.
The web app platform isn't complete; in fact, it's barely finished. Apple's MobileMe web apps aren't flawless, nor do the deliver feature parity with the company's established desktop apps that have seen nearly a decade of refinement. There's currently very limited support for offline operation; unplug from the Internet and there isn't much you can do. However, the pieces are all there and Apple can rapidly update its online apps to present new features immediately, without having to deliver new client software updates to every user. That's one of the most obvious advantages of web apps, in addition to being able to run nearly anywhere.
You get what you pay for
One of the biggest problems currently holding back the development of new web apps is the lack of a viable business model. It's hard to get users to pay for web services now that the web has become regarded as an entirely free medium. However, Apple has already found millions of paying subscribers for .Mac (including long time vocal critic Paul Thurrott), and will be selling MobileMe to millions of new iPhone users. Nobody else has figured out to sell subscription web services to millions of consumers as Apple has been, but Google, Microsoft, and Yahoo would love to do so.
Those ready customers will happily pay for the ability to connect their mobile to new custom web services and desktop applications. Further, Apple's hardware focus makes it the ideal merchandizer for web app developers; the company can deliver low priced deployment and billing services for developers with the intent of selling more iPhones and Macs rather than demanding huge overhead from developers, just as it has promoted its low priced, high volume iPhone Apps Store.
Security is another problem for web apps, as some sort of centralized authentication system is required to begin any type of secured transactions. Rather than each developer rolling their own security and authentication system, they could share MobileMe's. The presence of a centrally-secured market will result in rapid development of sophisticated new standards-based web applications. Safari's focus on developing advanced and fast JavaScript support will make it the ideal browser to use in rendering those applications on both the Mac and Windows PCs.
So where do Apple's MobileMe apps stand right now? The next Inside MobileMe segment will look at Apple's implementation of web email, how it compares with existing products, and where it needs improvement.
Comments
it doesn't work very well though.
*whisper*
it doesn't work very well though.
What part doesn't work for you? Just curious.
I have the family 4 plan and am a Windows/Outlook user. To my disappointment, i found out that Windows/outlook users are unable to share calendars. A call to Apple acknowledged this deficiency and a hint that there may be a solution coming but no commitment.
Anyone who is not a Mac user considering purchasing the family pack with the expectation of sharing calendars should consider postponing their purchase.
I am a Mac user mainly but have to suffer Windows too. I am installing Office 2007 to check this out on mobile me as I had an earlier unsupported version. What version of Outlook doesn't work for you?
UPDATE AFTER TEST
It all worked perfectly. People like C6Fan perhaps should not assume it is MobileMe not working, perhaps they have done something wrong. I was able to add a calendar appointment in Outlook and see it on MobileMe web interface and also on Mac iCal. Mail synced up too. Not found anything not working as advertised so far. This is PC running XP Pro and Office 2007, Mac is running all latest everything, iPhone is Edge version, latest software. Perhaps C6Fan is using older Office?
No need to "consider postponing your purchase"
Anyone who is not a Mac user considering purchasing the family pack with the expectation of sharing calendars should consider postponing their purchase.
I have the family 4 plan and am a Windows/Outlook user. To my disappointment, i found out that Windows/outlook users are unable to share calendars. A call to Apple acknowledged this deficiency and a hint that there may be a solution coming but no commitment.
Anyone who is not a Mac user considering purchasing the family pack with the expectation of sharing calendars should consider postponing their purchase.
See my reply above. Tested here and all works fine. Are you using the correct and supported Outlook?
*whisper*
it doesn't work very well though.
So true! My inbox in the web mail app doesn't refresh. Here's the senario: I start up the web app and go to the inbox. I then receive a few emails, I can see them on the web app as well as my iPhone. I delete a couple and read a couple. I check my mail on my mac mail.app client and it's in sync with my iPhone as it should be. The web app shows that the mail has been read. If I go to trash it shows the deleted ones, and those deleted messages are still in the inbox. No amount of browser refreshing or logging in and out will make it refresh. But If I delete one of the deleted messages in the inbox then the inbox suddenly refreshes and all changes are reflected.
This didn't happen at the begining of the mobileMe transition, but has been there consistently after the mail meltdown. Totally repeatable, different browsers, different computers. Totally sucks.
I'm not even touching on the fact that the mac applications aren't push either, which is really dumb.
Sheldon
What No SSL?
Data transaction security in MobileMe's web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple's cloud, rather than the SSL web page encryption used by HTTPS. The only real web pages MobileMe exchanges with the server are the HTML, JavaScript, and CSS files that make up the application, which have no need for SSL encryption following the initial user authentication. This has caused some unnecessary panic among web users who have equated their browser's SSL lock icon with web security. And of course, Internet email is not a secured medium anyway once it leaves your server.
If Apple applied SSL encryption in the browser, it would only slow down every data exchange without really improving security, and instead only provide pundits with a false sense of security that distracts from real security threats.
AppleInsider, you're missing some very valid security concerns. Sure, once you send out an email you don't have control over the encryption, but that's no excuse for me.com not supporting ssl for all its json traffic. The me.com web apps are mostly a convenience, say, if I need to use a public computer to check my email. Why should the web apps I'm using not encrypt my transactions so that no one can perform a man in the middle on me while I'm at a public library? I realize there are not a ton of use cases like this, but adding ssl for data transactions to and from me.com would be simple.
Furthermore, you didn't mention calendars, contacts, or idisk? You do realize that all those things are accessible at me.com right? And you do realize that your "once you send an email it doesn't matter anyway" argument does not apply to these pieces of personal data.
I think you guys should amend your article and point out why ssl does matter for the web apps at me.com. You made a good point that the html, js, and css don't need ssl, and by not using ssl for those things the apps will be a fraction quicker, but it makes sense to put json on a separate domain with ssl so all data can be protected. In other words, serve html, js, and css from http://www.me.com and serve all json data from https://secure.me.com
*whisper*
it doesn't work very well though.
LOL, indeed.
That and the definition of Web3 is still up for debate. Every expert has a different opinion.
If you haven't checked out http://280slides.com/ already... prepare to be blown away.
This is a hint at Apple's future and how it will compete with MS Office.
The addition of iWork apps to MobileMe would make it the next killer web app.
Mac OS X is doing a great job of competing with Windows Vista.
However Office is still strong and keeps people tied into windows.
If Apple can provide desktop-class web apps with online document storage they could really compete with Office on it's home turf. No software to install.
I expect this to land next fall when the next version of iWork '10 is released.
MobileMe in it's current incarnation is a little pokey and lacks the stability one would expect from a paid service. However, Apple is clearly preparing for the future and with we should see MobileMe truly blossom in the coming year once Safari 4 ships.
If you haven't checked out http://280slides.com/ already... prepare to be blown away.
This is a hint at Apple's future and how it will compete with MS Office.
The addition of iWork apps to MobileMe would make it the next killer web app.
Mac OS X is doing a great job of competing with Windows Vista.
However Office is still strong and keeps people tied into windows.
If Apple can provide desktop-class web apps with online document storage they could really compete with Office on it's home turf. No software to install.
I expect this to land next fall when the next version of iWork '10 is released.
Good to know you're positive about it. For now I hope Apple just gets my fraking email working properly.
But heck, are we going to redevelop every API, collection, GUI controls - the lot - in Javascript just for those two things? Why not just add them to Cocoa today and then get on with doing some real work?
And hundred thousand line apps in Javascript - yuck! That will increase debugging and maintenance costs over something like Java or Objective-C.
Good to know you're positive about it. For now I hope Apple just gets my fraking email working properly.
Here is another way to think about it...
MobileMe is like Mac OS X for the Web.
Just like the iPhone exposes people to the Mac experience on a phone...MobileMe will expose people to the Mac experience in a web browser.
The iPhone's OS is a mobile version of Mac OS X.
MobileMe is Apple's web OS and the foundation upon which it will build future web apps.
...But heck, are we going to redevelop every API, collection, GUI controls - the lot - in Javascript just for those two things? Why not just add them to Cocoa today and then get on with doing some real work? ...
No not every app is best suited for a web app.
For example FinalCut Pro or GarageBand in a web browser... not likely.
Word processors however, don't need direct access to the video card.
Wikis, content management systems, blogs, and most typical business apps would be ideal candidates.
MobileMe in it's current incarnation is a little pokey and lacks the stability one would expect from a paid service. However, Apple is clearly preparing for the future and we should see MobileMe truly blossom in the coming year once Safari 4 ships.
So in the meantime don't charge us for it then.
Here is another way to think about it...
MobileMe is like Mac OS X for the Web.
Some might argue that it's more like Vista for the Web- but that's besides the point.
Some might argue that it's more like Vista for the Web- but that's besides the point.
dotMac = Mac OS 9
MobileMe 1.0 = Mac OS 10.1
When OS X first came out it didn't have all the features of 9.
It was slow and felt like beta software.
By 10.3 things had changed dramatically.
Apple is putting alot of effort into laying a solid foundation for it's web platform.
Unfortunately this investment won't begin to pay off till Safari 4.
But Apple will continue to reap the rewards for many years to come.
Technically speaking, the JS library is way bloated and is no comparison to something like jQuery or Mootools. The downplaying of Flash is naive. Flash not only has incredible capabilities for rendering graphics, animations and movies, but also sport a mature language that could easily accomplish MobileMe functionality, and just about every internet browser/device has Flash capability- except of course if it is made by Apple. Also MobileMe even uses Flash for picture uploads.
I also am not convinced that having a web page function exactly like the desktop client is really the way to go, each is used differently. Most peoples email client stays open all day long, so it needs to refresh and be statefull, but webmail is often accessed for a brief time, the the refresh issue is really not that relevant in that case.
Also, do your research on Ajax over SSL, you will see why Apple does not encrypt.
I like the other articles about the iPhone, this one just seemed over the top with its bias towards all things apple, even for being on AppleInsider.
-t
All the functionality that exists in MobileMe has existed in a more robust, scalable and arguably usable fashion with services such as Gmail or Yahoo for years.
Technically speaking, that isn't even close to being correct.
Technically speaking, that isn't even close to being correct.
Care to elaborate?
Email, check
Photos, check (through Picasa- many more features)
Contacts, check
Calendar, check
iDisk, half-check (through gMail or Docs)
So, pretty close...and Google is free, also supported in iTunes, iCal, Mail, etc...
So what does that leave MobileMe with? Well, it sure looks pretty.
Care to elaborate?
Email, check
Photos, check (through Picasa- many more features)
Contacts, check
Calendar, check
iDisk, half-check (throught gMail or Docs)
and Google is free, supported in iTunes, iCal, Mail, etc...
So what does that leave MobileMe with, it sure looks pretty.
I really don't have to elaborate as your "half-check" admittance shows that that "all the functionality" doesn't exist, but elaborate I shall...
For starters, and this is a biggie, you are leaving out Back To My Mac and syncing across all Macs of the iDisk, System Preferences and most user settings like Dock Items, Bookmarks, Dashboard Widgets, Keychains, Notes and all your Mail Settings, including rules, sigs and smart mailboxes. It also keeps this stuff updated among my machines automatically, and now even with PCs to some extent.
More specifically, iDisk also provides up to 20GB of cloud storage with 200GB transfer per month. This can also be used to share files publicly or privately. There is also a web hosting on me.com and very simple publishing from iWeb and iPhoto.
At least the Bookmarks can be synced and stored with FoxMarks, but that isn't the same as having a one stop sync service for everything. Even that requires a separate login which you have to create and maintain.
Another issue is if I am setting up a new Mac that I just bought I can't just put in one username and one password when I first turn it on to have 99% of my entire setup pushed to my new system. With Gmail it's all a bunch of manual setups in different apps: Mail, Picasa, even the installation of the plugin for iPhoto to connect to PicasaWeb. I don't know if there is a similar plug-in for iCal or a local Google calendar app as I don't use that feature. I say 99% because MM copy doesn't store my desktop photo for some reason so that one item has to be done manually. Woah is me, right?
Google also doesn't offer Push email. Yahoo does, but it has worked so well in the past, but that is neither here nor there as they offer less than Gmail when it comes to providing all of MM 's functionality.
If the functionality provided doesn't fit your needs then MM isn't for you or that all the functionality of a free service or services combined suit your needs that that is fine, but to say that Yahoo or Google offers all the functionality of MM is simple not correct.