Imagine OLE reinvented for the web and that's 90% of Microsoft's Fluid Framework: We dig into O365 collaborative tech Microsoft is previewing its Fluid Framework, first announced at its Build developer event in May, and presenting it as a key technology for content-based collaboration. Fluid Framework only occupied a brief and minor slot in CEO Satya Nadella’s keynote at Redmond's Ignite conference, running this week in Florida, yet the …
I've been suffering from insomia for a while and remember fondly those days of Inside OLE 2. a Monty Python reference at the start of each chapter to try and show you have a personality then the most dull content ever committed to paper. anybody who reached the end deserved a medal.
We had copies of his videos of presentations at MS. Nobody finished the first one.
Anyone taking bets on how many milliseconds between release and when there's an exploit in the wild for some nefarious purpose? I seem to recall security issues arising from the original OLE in the early days of Internet.
Mine's the one with the hatstand in the pocket. -->
That's not even the scariest part of the quote...
'We want to break down barriers, move ideas seamlessly [...] across people [...]'
As soon as you have multiple people involved, the first question must surely be "What is your security model?" and if you don't have an answer then I have no further questions.
So what? Internet is first a communication technology, all the "web" stuff that was built upon it is just a use of such communication technology. Desktop application can communicate like any other one - you don't really need that HTML pages display application called a "browser" to do it - you don't even need HTTP (with all its downsides, having being designed to select and display, one-way, simple documents) or HTML.
The actual biggest IT problem is to think everything has to live in a "web page".
Can anyone name uses of OLE which were useful other than the "Excel table in Word document" example? I've recently thought about all these compound document technologies from the 90s and it seems they had awful ROI. Lots of engineering time across many companies wasted on a feature that had such a low impact.
It was useful especially when different people worked on different parts of the same documents at the same time and you didn't have the latest data available when inserting external data - tables, charts, images. You could insert a draft and keep on working on the rest of the document.
Or you could embed another object and work with it directly without having to go to a separate application. I.e. it could be more powerful to work with an embedded Excel worksheet than a Word table.
The downside was all data (when linked) and all applications used had to be available. When most documents were still printed to be used (i.e. the 1990s) it was less an issue.
But it required skilled Office users - and most Office users aren't skilled and don't understand the most advanced capabilities.
My company "templates" are still mere typographical layouts designed by people without any clue about styles and document automation.
Office for many is still a typewriter with a screen.
>But it required skilled Office users
and stable and robust Office applications specifically Word...
When I worked in pre-sales we were often putting together multi-section documents that at times spanned 3~4 80mm lever arch files. The pain was pulling it all together on early 1990's Windows systems, however, it demonstrated that Word whilst good for letters, CV's and short reports was out-of-its depth with these larger compound documents. It was a shame that integration with Desktop Publishing software wasn't as simple as OLE.
Reminds me that even now MS don't really have a Desktop Publishing solution - is there one for OpenOffice/LibreOffice?
Lots of examples. The problem has always been how damn flakey OLE is. When I first came across it I thought "Great New Wave, but with better applications" except while HP's New Wave worked seamlessly but just never had any applications which were worth using. OLE in office so often just curls up into ball and dies, taking all your links with it.
If they can make it work this time I'd find it very useful. But I won't hold my breath.
The thing I never understood about office was why Word, Excel, PowerPoint etc were different programs. OK, I know it is due to history. But they should all have been merged into one seamless whole decades ago. So the editing the notes page of a presentation should not be any different to editing a page in a word document. WTF can't I have the style gallery from Word in PowerPoint etc... They're not a suite at all, they seem to be three separate members of the same family who haven't been on speaking terms since birth.
If they could integrate the tools on the same system I'd have more faith in them doing across the network. But how many goes have they had at getting master documents in word working? I thought the one in Office 365 was working better when I played with it a couple of month ago. Great I could assemble a whole book from a series of chapters. Only to find that when I tried to open the files a couple of months later it was all broken again. Then I found when I tried to assemble a set of chapters someone else had written in Word that it wouldn't stick them together properly and insisted on corrupting each of the individual .docx files into the bargain.
So, yes I'd love this to work, but I'd be surprise (please but surprised) if this worked any better than any of their previous failed attempts.
OOXML already provides the foundation for sharing components, but it isn't pretty, and has rudimentary support for versioning, though in practice this can't be done without some kind of server such as, eugh, Sharepoint. This sounds like an extenstion or transition of this to use HTTP2 and HTML5. Clients are all registered so changes can be signed and the VCS handles the merging. I suspect "collaboration" will be less important than plugging in remote data sources for dashboards.
"Another fine mess that MS has gotten us into..."
You would have thought that they might, just possibly have learnt their lesson from old time OLE?
What am I thinking? That was the old Microsoft. This is the new lean mean MS that just copies everything in sight even if first time around... it was a POS for 99% of people.
Thankfully, I can steer well clear of this as I am now in an MS Free Zone.
Stand by for reruns of scenarios such as Very Important Boss going ballistic after giving Very Important Powerpoint Presentation, having discovered during said presentation that linked spreadsheets have been changed or deleted since the masterpiece was created.
Liking the idea of branching / merging changes too : Subversion for Office! Imagine the fun for the accounts department trying to unravel the chaos of error strewn changes that have been simultaneously made by multiple incompetent users to a large spreadsheet, with only a diff tool to help them.
A system for transactional integrity, ensuring that recent changes aren't deleted by a newer commit of an older version that someone else has been working on? That doesn't seem to have occurred to them yet, but it's important in business data - and we all know how excel speradsheets get used as surrogate databases by users when proper systems haven't been provided for their needs, and how arguments arise about who made which change to whatever version got emailed around......
Amongst the many problems that this brings is that it takes people's/users attention away from their work and puts the focus on how a bunch of programmers *think* they could work. In the Real World, we need to pass around invoices for approval, POs for completion, works orders to get something done, a spec to persuade a bunch of coders that there *is* a Right Way to do things... All of these really mustn't be dynamic, practically all of English jurisprudence is predicate upon something from the past staying as it was in the past. Imagine an IT contract that was 'dynamic'? Interesting technological thing, but don't let it near SpaceX or NASA. Or the US military, or the UK MoD. Imagine the SA80 cockup with this involved in its genesis....
All this is stuff sounds great but...
Think about it: OLE - or embedding bits of one document in another - is the illegitimate child of GOTO and(!) COMEFROM.
We have moved beyond those things in programming, time to do so in terms of documents
I have seen what I think they are aiming for - sort of like a dynamic dashboard or a nagios screen.
Those things run off structured data or a warehouse where the structure and location of data _does not change_.
Documents do change and are moved.
Ehm, really? All those "applications" that download a storm-s**t of dependences from the web every time they're run are actually different and better?
If each part of a document is versioned and it is possible to set a baseline for a given release, it won't be much different than asking for a given library at a given version in your web page....
Yes, they are ... different (better - that is a big stretch).
For that library that does foo, in 12m time you can reasonably expect it to still do foo, otherwise you would not have an external dependancy.
It is cultural (in programming) that if you change something - like adding a warplane option that breaks earlier versions, the old version is still there somewhere.
This is not the case with a document.
This document may be deleted or moved or updated, it may have been the lyrics of 'everlong' last year but this year it is 'times like these' and that might or might not be right for you.
If two people link to that one document it will probably be wrong for one of them.
Indeed two people will probably be fighting over foo.
To make this work you will need to do what uber wants to force american pedestrians to do - only cross at crossings and look both ways (and at all the possible points of impact) or get run over.
whereas programmers will seek foo - the fruits of a good icon - in the obvs place
Only if the documents, or its parts, are not under some kind of version control. For the matter, any external library may disappear - it happened - or become incompatible. Unless there's a versioning system.
With a working version control system if you link version x.y.z of a spreadsheet or of an image or a subdocument, you know it will exists and it won't disappear.
Of course that model can't work with people that pile up files with version information somehow in the file name, usually not even following a specific schema.
Just how often is this idea going to be useful? First most people have limited skills on Orifice and this appears to be beyond their skill set and pay grade. Also, just how many documents need this kind of interactive editing. Again, in some areas were document control is important can one follow the versions correctly and make sure those who need the current version have the correct version. What Slurp is overlooking is there are many who need a stable version for their part of a project but will not be involved in any editing of the document. For my group we do not edit documents but need the current, stable version of it to do our work. Allowing every mindless idiot to update the document could create havoc as we would not know what is correct and what is still currently being revised.
>Just how often is this idea going to be useful?
The idea is useful if implemented within the correct context. Documents, like program files are really just objects. Behind the scenes you need some form of version control, currently many simply use out-of-the-box Windows and Office, which have no in-build version control functionality.
Using Office with a document management system or version control system (such as Subversion or Git) things change as you don't save a file you save a document and its 'makefile' associations - just as you do when signing source code in/out of it's associated repository.
In theory, with cloud, this should be much easier as you are not relying on (all) users installing the right packages on their under spec'd PC's etc. As for whether people need it, well with cloud it should be a simple share thing: I tell the system: the purpose of the distribution (draft for editing, draft for review, issued), the email addresses of the people I wish to share it with (including none) and the system sorts it.
What do compound documents look like in the internet era?
HTML. Next question?
And, of course, there's already a tremendous body of research, in fields such as digital rhetoric, HCI, and CSCW (Computer-Supported Cooperative Work), on breaking the monolithic-document model and replacing it with robust, stable, versioned, extensible views of common data. I know of a couple of such systems that have been in production use for years. I have to wonder how much attention Microsoft (which has often been plagued by NIH, even among its own divisions) is paying to that existing work.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
