Into a Binder
Office 95 includes a new application called Binder. It allows you to take Office
documents and put them into a composite file together. Binder embodies the
concept of putting the contents of a folder (or a directory) into a single
object. You can then switch among the various objects in a binder, and Binder
does all the in-place editing activation necessary using OLE 2.
How does it work? Binder uses Structured Storage for its file store. For
example, I created a new Binder object and dragged and dropped the composite
Word-document object into the binder. Then I created a new Excel object in the
binder (see Screen 5). Look carefully at this structure. It has two main Binder
objects, called 1 and 2. The first is the Word document with the Excel and
WordArt embedded objects. The second is the Excel sheet I dropped into the
binder. Finally, look at the standard Binder type at the top level, together
with its SummaryInformation and DocumentSummaryInformation streams.
Are you starting to see a pattern? The reality is: With Structured Storage,
Microsoft has been running file-sized full-blown object filing systems. Indeed,
a Structured Storage file could be regarded as a full-blown storage engine in
itself-a sort of prototypical Cairo Object Filing System! This is why, when some
corporate IT managers call Microsoft's ability to create an Object Filing System
into question, I point out that there are already hundreds of millions of
documents out there that use Structured Storage and they work just fine, thank
you. Microsoft has been using this storage engine in Office ever since version
4.x.
Binder is important, because it's the first application from Microsoft that
works "one layer out" from the main applications. Binder is a
container of Word, Excel, PowerPoint, etc. objects. As such, it is effectively
an active container surface into which you can pour data objects to work on
them. Imagine the Windows 95 shell allowing direct Binder-type operations, and
you can see how a Cairo active desktop might well be a container system itself.
Near Future
Now, let's make a leap sideways to a forthcoming piece of software from
Microsoft-Exchange Server (see "Groupware: The PC Team Sport" on page
33). As you may know, Exchange Server replaces Microsoft Mail and brings, at
last, a full Messaging Applications Programming Interface (MAPI) to the desktop
in a proper client/server email system.
However, Exchange Server has more important tricks up its sleeve. It has Public
Folders, which automatically replicate data among Exchange Server engines around
your enterprise. If you wish, you can use Public Folders to store email. But
it's far more potent to drop Structured Storage files in them. Just fire up File
Manager (or Explorer, if you're running the Windows 95 shell), and drag and drop
a pile of Word, Excel, and PowerPoint documents into a Public Folder. Exchange
Server swallows up the files and stores them within its active storage engine
(see Screen 6).
Now the magic can really start. Look carefully at the columns in the Folder
view-no great surprise. There are columns detailing From, Subject, Received, and
Size. However, after a little fiddling with the Folder columns settings, I've
made dramatic changes to the information shown (see Screen 7). Exchange Server
is "surfacing" the properties applied to each object-in this case,
Manager, Client, Value, and Authorised. Manager is a standard property held in
the Summary tab of the file Properties window in each Office application. The
other three are custom properties that I added to each object (see Screen 8).
Since Exchange Server is storing these documents in an active repository, they
can be replicated and distributed around the organization. I can attach full
security rights to the Folder and its contents. But most important, I have
completely removed the importance of the filename from the object. No longer do
I need to refer to an object only by its filename.
Although Windows 95 and NT have full 256-character filenames for files, that's
far from enough. Length is not the issue; the granularity and the number of
attributes that can be attached to an object is the real key. For example, if I
want to mark all the files belonging to Project X, I don't want to have to put
Project X into each filename. It would be far better to have a Project Name
attribute attached to each object. And Structured Storage, Office, and Exchange
Server allow me to do this. These tags are stored in the SummaryInformation and
DocumentSummaryInformation streams. Each Structured Storage Office-compatible
application has these streams, even for subobjects in a compound embedded
object.
Power Exchange Operation
For anyone interested in a really powerful document management system, Screen 9
should raise the hair on the back of your neck. Exchange Server has, at my
request, sorted and collated the objects in this Public Folder by the Manager
property and presented the results in a tree diagram. You can collate up to four
levels deep, so there's no problem displaying a tree of customers, where each
customer's information is sorted by "Invoice Paid? Yes/No" and then by
date, or something like that.
If you attended the December 1993 Microsoft Windows "Chicago"
Professional Developers Conference in Anaheim, California, you'll probably
remember the awe-inspiring demonstration of Cairo given on the first day. The
sorting and collating I've described was demonstrated as a Cairo feature.
On to Cairo
At this point, I must make it clear that I'm dropping out of the realm of the
known and into the realm of informed speculation. However, what I'm describing
is logical and consistent with the above.
Exchange Server uses a modified Jet database engine for its storage. It's known
that Cairo has a native Object Filing System (OFS) based on the NT File System
(NTFS) disk format. NTFS is a very flexible storage engine and has many features
similar to those of a transactional database engine. For our purposes, the most
important feature is that each file object can have an unlimited number of
properties attached to it. (I don't want to go into too much detail on NTFS.
Suffice it to say, Helen Custer's Inside the Windows NT File System from
Microsoft Press is required reading.)
Reading Custer's book and matching it up to the Exchange Server and Structured
Storage information, coupled with discussions with senior Microsofties, leads me
to believe that NTFS will be extended under Cairo. It will appear to be
backwardly compatible with the current NTFS, but it will have a whole new set of
active processes running on top of it. In other words, the Jet database-style
engine of Exchange Server will be replaced by the Cairo OFS, based on NTFS.
NTFS-based OFS has everything you need: It can hierarchically store objects; it
can index on properties; it can store Custom properties; and it is robust and a
proper filing system. For example, when you save a Word file, it talks to the
local OLE storage engine running on your machine. This engine creates the
Structured Storage disk file, and Word pours its contents into the file. The OLE
libraries manage all the file handling.
When you store documents in Exchange Server, Word talks to the OLE storage
engine which talks to Exchange. Word basically pours its contents into the
Exchange Server engine, again via the OLE libraries. No major changes were
necessary to allow Word to do that. In the Cairo future, the OLE libraries will
talk to the Cairo OFS store, and Word will pour its data into that instead.
What more will Cairo uncover? Exchange Server only sees the outer layer of the
onion. It doesn't look inside the Structured Storage object. It pulls out the
SummaryInformation, but embedded objects within the document are still hidden.
Cairo will actually break a Structured Storage document into its component
parts. This will allow it to display all the components in the document and to
show all the standard and custom Summary tags for each object too. Remember,
each object in a compound document has its own set of tags.
This revealed structure will enable multi-user document creation and editing.
Since Cairo, by virtue of its NTFS host, will be able to do database-style
record locking on each individual component of the Structured Storage document,
it will be possible, for example, for several users to work on different parts
of a compound report, enabling much finer document indexing and retrieval
processes. After all, a list of "hot words" on each object is just
another set of custom property tags that can be individually indexed, sorted,
and collated in the Cairo OFS storage engine.
The Path Is Clear
By focusing on how Structured Storage works and the benefits it brings, you can
see the direction that Microsoft is taking and how Exchange Server is a big step
along that road. Ignore all the email parts of Exchange Server, and look
closely-it's really Cairo 0.75.
It's also important to realize that Cairo won't be just a server-side solution.
To operate at its best, it will need client-side applications that understand
both OLE and Structured Storage. It's not surprising that Microsoft's own Office
product has been doing precisely this for the past two years.
I'm told that there will be a clean and simple upgrade path from Exchange Server
to Cairo itself, when Cairo is ready to ship. Indeed, Exchange Server 2 will
probably be fully Cairo-hosted. This is a sweet victory for Cairo, because all
the indications are that Exchange Server 1 was never really supposed to happen.
According to all the time scales and published plans, we should be running on
full Cairo by now.
The delays in Cairo-and in getting NT 3.5 out the door-mean that Microsoft had
no choice but to put together an interim solution. Exchange Server 1 is that
solution. And although it may be an interim solution, it offers some extremely
interesting technologies for the future that you can put to work today. The
exodus from the filename starts now.
Register
