Wearable Computing, why I don't think Apple is making an iWatch

Here's some barely edited, off the cuff IT speculation for you:


So wearable computing has been getting some press recently and of course people are coming out of the woodwork to say that in a year or two Apple will release their wearable device and the market will take off.  While this is probably valid and it fits Apple's M.O. to wait for smaller companies to setup a space and make some gaffes, most of the speculation has been that Apple will enter the smartwatch space based on patent applications and  acqui-hires by the rounded-corners giant.  Recently some people have been reporting that Apple's interest may have waned due to consumers not buying into smart watches at all.  The space remains pretty stagnant and it's likely that the gaffe right now is to even get into it.

However I can't imagine why a company like Apple would go into smart watches to begin with, even if the market for them was thriving.

Put simply, the other half of Apple's mostly winning strategy the past decade and a half or so is to distill the experience of whatever product down to a few of the most useful and simple features, and them package that up in a way that's tightly integrated with the rest of Apple's offerings.  The key common ground with all their devices has been the iTunes platform, where they've spent massive amounts of money on development and licenses for music, movies, newspapers, books, games, etc.  The iPod started as a music player, and iTunes sold music.  Then they added pictures, and then stepped to video.  And then iTunes sold movies and TV shows.  With the iPhone the iTunes application became a sync hub for that media plus an address book backup and a mobile app store.  I think iTunes got into books a bit before the iPad came out, but it's pretty clear that a major use case for the iPad was as an eBook reader.  This has all made sense, but the idea of them making a watch does not.  Listening to music on your watch is no good.  You'd be running a headphone cable to your wrist, and you use your hands and arms a lot during the day.  It's clumsy.  The screen is too small for movie watching to say anything of reading a book.  You probably couldn't play games on it either.  So why would they abandon everything they've done and make a watch that doesn't play to their strength of an integrated ecosystem?

My theory is that if Apple does enter wearable computing it will be with a Glass-like device.  It makes more sense.  It's something that they can make look good, as a major criticism of Glass has been that you look like a doofus while wearing it.  They could let it bluetooth pair with your iPhone to access its media.  It's a superb platform for listing to music and I bet it'd be a pretty good reader too.  They could integrate it with Apple maps to provide a HUD.  Probably a dozen other things I can't think of.  It'll be the iEyes or i^2 or something.  This is of course providing they're even thinking about it, but they may just see wearables as a fad for now.

That's my story and I'm sticking to it.

--PXA

Checking for life...... Not found.

Since the last update to BE, RIT has been bending me over the desk as is its custom. I have a small amount of time free at the moment and I feel I need to keep a modicum of momentum in my quest to have a regularly updated web log. Since I have nothing major to report I will just summarize.

RIT SG:
RIT Student Government Elections are this week, I have already voted. My initial thoughts on the election can be found at the RIT Sentinel:
http://sentinel.ironcouncil.net/2008/04/07/sg-election-time-2008-edition/

As a note, apparently SG will actually count votes for the cockboat this year.

Unfortunately, due to academic concerns, I was not able to make it to the RIT Parking Advisory Group meeting this month. Which is actually quite a pity considering I finally don't have class or work during the hour of the meeting and would've have been able to go if my System Administration lab hadn't taken 6 hours to do. It's hard to find the time to be politically active.



Google Sync:
I have made a pretty decent amount of progress on the Exchange -> Google implementation, however there are still some problems translating Microsoft to Standards. This makes for some annoyances when applying recurring appointments. I was hoping to avoid having to parse and then reassemble the RRULE myself, but this appears to be the only way to get Google to play ball. The UNTIL clause of some RRULEs uses a date/time format which looks like "20080512T010000" or yearmonthdayThourminutesecond. According to Austin from Google's API team I should be saying "20080512T010000Z", I don't get why something that is likely just looking at the day/month/year stuff cares about what timezone the stamp is in (Z refers to Zulu time which was an older name for what became UTC)


Samba:
Recently a co-worker upgraded all the Vista computers in the office where I work to SP1 of Vista, which generally went unnoticed until he went to update our department's intranet site (called DSWeb). DSWeb has been a bit of a pet project for a while for me, working on my sysadmin skills in a practical application environment. The new update to Vista breaks the way it talks to standard Samba servers. Windows based shares (Win 2k3, XP) are likely not affected but the open source implementation Samba, which emulates bits of Windows networking in Linux to allow Linux to do things like Windows File Sharing or join Active Directory managed domains, cannot speak the new dialect that Vista is using. Something about SP1 causes Samba to fail decrypting the challenge when a Vista machine is trying to authenticate. After much misadventure I found that Samba released a bugfix version, 3.0.28a, to address the issue. This is generally marked as unstable or testing by most distributions and must be explicitly installed at this time. However, I have seen no major issues with it and it did fix the Vista issue without even having to modify the configuration file.


Steak & Whiskey Night:
Back in the fall my apartment began a celebration/tradition called Steak & Whiskey Night. It can be celebrated at any time, as often as we want to. This became quite popular, even in the short span of time it existed before Rochester weather became too cold to enjoy the outdoors.
This May, Steak & Whiskey Night returns! It is currently planned for Friday, May 2nd. Attendees are encouraged to bring their own cuts of meat or custom steak rubs. It promises to be delicious.


Graduation:
Is approaching, that is all. With any luck if I can hack around some requirements and get another co-op soon, I will likely be RIT Alumni come next Winter. This concept is bizarre, and frankly a little frightening. I have paid over $32,000 a year for 4 years of my life for this education, and everything I consider at this point to be a marketable skill I have no learned from RIT. I have taught myself, or learned on the job. When my knowledge and RIT's curriculum overlapped, I was told I was out of luck and had to sit through their version. My self-motivation and ability to learn very technical skills on my own was NOT rewarded like I always thought it would be in college, it was effectively punished. So...if they're not going to teach me anything...and I'm not learning anything...Why am I paying this much again? And why does this degree matter? ...Do these skills even matter?

It's probably just Realworld-phobia. I hope.

Syncronization again

Google has, in some ways, beaten me to the punch. For this I am actually grateful, since they built the calendar service, and the GData API they should have figured it out before me.

Unfortunately they're doing so in a bit of a different way than I am going about it so we may still be leaving some people in the dust.

The Google Calendar Sync utility:
http://www.google.com/support/calendar/bin/answer.py?answer=89955

The nature of the tool requires you to be using Windows, and Microsoft Outlook which is problematic. I primarily use Linux with Thunderbird at home, and I have the Lightning Thunderbird plugin to allow me to use it for calendaring. At the office I do use Windows mostly, but spend some of my time in Linux and Evolution or using Entourage on the Mac. Google cannot help me here.
The utility itself is a compiled executable and Google has not release the code, so developers don't know how the tool works. The Terms of Service also prevent developers from reverse-engineering to find these things out, so our only hope is to ask Google how this thing does what it does.


On a related note I've been making some progress with my own sync tool, but Spring Quarter here at RIT just started so my time is growing slim. With any luck I should have a working beta within a few weeks, but that probably will have limited support for recurring appointments, at best.

-PXA

(Edit, I went to retag this and blogger.com ate some of my article. Looks like their regex got a little too greedy)

Questing for the Holy Grail (Of Calendar syncronization)

I have successfully completed a proof of concept script in python, which connects via IMAP/SSL to an IMAP enabled Microsoft Exchange server. It IS possible to pull Exchange calendar entries through IMAP, once stripping off some of the MS style fat from the returned data, we have what is more or less iCal (RFC2445) data.

The number one Google term for python iCal is an old module written by "mxm". This was parsing the dates wrong, and it seems like Microsoft has done a strangely good job with implementing the standard and the module is actually doing some highly unnecessary mangling of the string. I'm still working on my own script but will eventually fix this and try to merge the fix back upstream.

I also uncovered a nasty glitch in Microsoft's implementation of the standard, and they were doing so well. Though probably not strictly a problem, Google's API isn't forgiving enough to let the deviation slide. According to the LETTER of the iCal RFC Recurrence rules which specify weekly recurrences on specific days of the week are allowed to have multiple values separated by a comma. EX: BYDAY=Tu,Th,Su for Tuesday, Thursday and Sunday. Google takes this literally in the sense that there can be ONLY a comma between days. Microsoft has been a bit more liberal with its implementation and places a single space after the comma. Google sees it and vomits out the wonderfully descriptive "Bad Request" error. No wonder it took me around 5 hours to track it down.

Now, as much as I love standards, throwing a hissy fit over something like this is a little much. I have recorded this as an issue with the Google Data API. It is here:
http://code.google.com/p/gdata-issues/issues/detail?id=371

That being said I have managed to work past these issues and have a pseudo working script to sync from IMAP enabled Exchange to Google calendar. It is not ready for public consumption yet but can be made available on a case by case basis until it is to anyone who asks.

For those of us who live by the Exchange calendar...
Coming soon: New and improved Google Calendar! (Now with useful!)

--PXA, OUT!