It seems that MS are entering the hosted Office space with
Office Live, Q&A
over the downloads link)
. Here are some of my initial thoughts, at least
crystallising my dislike of some of the 'cloud' computing hype.
This appears to involve putting a full-blown instance of MS Office on the
server, per user - this is (presumably) one of the reasons they are on a
server farm building spree: and who can blame them - running at
least one full copy of office on the server per user is going
to be incredibly
This at least lets them expose the full feature set of MS Office,
and makes it something I'd want to use - the down side being things
like those Excel no
features mean a casual user can swallow gigabytes
of server RAM fairly trivially:
Total amount of PC memory that Excel can use
Old Limit: 1GB
New Limit: Maximum allowed by Windows
I hope that works out well for whomever happened to get dropped into
sharing the same server as the heavy spreadsheet user.
What about the web technologies
? - apparently this is not Silverlight
only, though there seems to be an acknowledgement that if you want a version that
performs well, you will need that, otherwise (reading between the lines) I suspect
it's a lot of bitmaps, lag and server side rendering.
The exact technology mix doesn't seem to be public yet, but the MS Office
code-base is mythically large and twisty. Having said that they seem to have
a Model/View separation clean-up underway, unless the live collaboration is
some grisly hack. I strongly suspect, where claims of
perfect visual fidelity (6:05 into the video) are made, that this is a
model, or perhaps even more basic - with EMF+ or even an RDP-like protocol
being used with a -very- thin client, ie. a model akin to Ulteo's
embedded-Java/VNC style setup.
Of course, this type of architecture is really great for getting apps onto
the web fast, and sharing that code-base with the fat client, but
ultimately can never allow dis-connected operation. Then again, for large
complex applications I've never believed the "re-write everything in
mantra (after all, we've not yet finished the
re-write of everything into Java yet), and it seems (to me) an expensively
lame solution to the simpler deployment problems the web is supposed to
Normal Web problems
This of course ties into the problem of payment - sure, in this world
people can save money by buying some trivial piece of hardware, and
running just Firefox on it; but sadly - unless money can be made simply
by competing to give things away faster than Google, or by advertisements:
someone has to pay for 10k new machines per month, and worse the electricity
to run them. Is there some corresponding, functioning micro-payment /
metering scheme to make a business model fly here ? and how does the
transition to that work ?
Then of course, service level agreements tend to be an issue - particularly
in the presence of the known pathological resource sharing problems. Of course,
service wise - there needs to be some really good sand-boxing to isolate
everyone from the next MS Office binary filter vulnerability, and no doubt
there remain many of them to be discovered.
To overcome some of these problems, and the potential confidentiality /
compliance issues people can run this on their own Sharepoint server(s)
then, if you're not careful this begins to look like some of the lamer desktop
'virtualisation' solutions that essentially are just an exercise in PC
movement: all the PCs move into the data-centre: but you have just as
many of them, perhaps at greater expense, but at least they sit somewhere
else. Still - that should make hardware manufacturers salivate I guess.
Of course, in the browser world, as I understand it, there are a host of
evil problems with missing open standards and ergonomics around interacting
with local devices, and exposing those back to the server: USB keys,
printers, printer-quirks-and-settings, 3D acceleration etc. Perhaps many of
these can be overcome with Silverlight, but no doubt eventually deploying
and updating increasingly complex fat-client technologies starts to eat
into the 'reduced deployment' rational for all this work in the first
place. It reminds me of our old XMS system (written in Java), that only
worked (or was certified / supported) with Java 220.127.116.11-5.6, and only on
Windows, and only in IE, such that everyone had to use Citix to access it
on a Windows cluster in Provo.
Win32 for the Web ?
If my guess is correct: that this is some very thin RDP-like layer
to a fat client on a server - and indeed for eg. VBA macros, Excel analytics
plugins etc. to work well this is basically necessary (since they can use any
part of the Win32 API) then life is interesting. It would suggest a possibility
to extend the life of the Win32 APIs to become a 'web' application framework:
if so, surely ~all windows desktop apps can be "Webbed" in a similar
way. If my guess is not correct, then at least some degree of embarrassing
retraction wrt. the functionality available in the web version will be due
soon, and/or some wholesale feature axing for Office 14.
Does this mean Microsoft is finally shipping Office for GNU/Linux ? lets see
how it performs there, I guess this is at least better than nothing for the last
few percent scared of the GNU/Linux desktop and OpenOffice, and it'll be interesting
to see if MS bothers sustaining their increasingly creaky Mac version: apparently
the Web version on Mac will be more feature complete, albeit less 'beautiful'.
This is a smartish move by Microsoft. It will make, thanks to Miguel's prescience
MS Office available on the GNU/Linux desktop. However it will cost Microsoft a fortune
in server hardware and electricity, and there are formidable problems around
metering and managing the live service, particularly against a leaner, simpler
free (beer) rival in Google. Of course, as soon as the half of computer users with
laptops go dis-connected, or catch a flight (when can we expect high-bandwidth,
low latency transatlantic internet services ? or even ubiquitous in-seat power ?)
- they will have to use OpenOffice anyway, oh, and their portable hardware will
need to be beefy enough to be capable of running that, so - why not author
it there in the first place ?
This is a problem for Free software - traditionally it has been hard to fund
even simple and lightweight shared services (eg. freenode) - never mind server
computing on this scale. This is an architecture only giants can play with, as
such there is much hope that it will come horribly and expensively un-stuck. It
is yet more of a problem as RMS has pointed
because people have no control over their software - they surrender all
their freedoms (if it is even implemented with Free software) to some all-knowing
A great Free-software response in my view is to work on adding collaboration
features using existing protocols, I'm a fan of bootstrapping from existing IM
services with Telepathy
and sticking with the fat clients. That keeps your data local, and shares it
only transiently with people you trust, and it also requires little-to-no server
load, just bandwidth. We should also keep adding features that (so far) are
not going to work well in the 2D fat-web space: eg. get some more sexy 3D
transitions going, and better native Mac integration.
Finally - poor ideas don't die, they come back to haunt us; the idea that
there would be a few large powerful computers with lots of terminals is a
perennial, and goes in cycles. In the past it has foundered on the rocks of
Moore's law - it turned out to be cheaper
, easier and more reliable
to put almost all the software, data, and processing on the local device.
Enabling dis-connected operation will still mandate beefy thick clients.
I'm optimistic that the trend will continue - eventually even for Mobile
devices, last time I looked Google develops and deploys some fat
I look forward to trying the tech. preview at the beginning of next year
to corroborate my suspicions, or the final product in Office 14 in