Re: OLE? KDE?

["David J. Orme" <david coconut-palm-software com>]

Dill wrote:

> Is the Gnome OLE (Baboon?) just a clone of the Microsoft OLE?
> What are the differences between the one KDE uses?
> I've seen lots of talk about the two different implementations but I really
> don't know what the differences are.

Okay-I'm not one of the developers but I was hacking around in its sources yesterday so I'll offer a preliminary
analysis.

Baboon is very similar in spirit to OLE, with some similar implementation ideas, some different ones.  Many of
the implementation decisions are still undecided, in particular, how embedded documents will be stored.  The
options I saw batted around were: 1) A file system within a file (Microsoft's approach), and 2) XML/Ascii (would
make it possible to hand-tweak or fix corrupted files).

Others can probably fill in more details.

While we're on the topic of storage options, I'll add some comments drawn from bad experiences with Microsoft's
model.

- The File System model is *very broken*!  Xml is better, but only because it is possible to hand-tweak it.  It
doesn't solve the fundamental problem.

- Microsoft's fundamental problem with OLE (and the registry too) is that they are essentially binary databases,
but without the security and reliability of a server program.  In other words, if Microsoft Word crashes, you
might lose anything ranging from the documents embedded within your Word document to the entire Word document.

- The registry suffers the same problem.  I once had a beta version of Netscape crash while it was in the
process of exiting and writing its registry entries.  I tried to hand-tweak the registry through regedit to fix
the damage, but eventually had to reinstall Windows to fix the damage.

- There has been a known solution to this problem for a long time!  Just do all of your reading and writing
through a server, protected by transactions!  Then if some user application crashes in the middle of a
transaction, the application server just rolls back the transaction and the user only loses the last
transaction, not the entire document.  In the case of compound documents, this tends to imply using an object
database (or maybe an object-relational database) for storing the program's data because this type of database
is optimized for large objects and long transactions.

Of course this raises the question of "what is a transaction?"  In a database, transactions are typically broken
down to the record level.  While the cursor is on a row, there is a transaction active on that row for
modification purposes.  When the cursor leaves that row, the transaction is committed to the database and a new
one is opened on the new row.

In a word processor, this might be extended to paragraphs.  Each paragraph object would be edited in a separate
transaction and a new transaction would be opened and the old one committed when moving the cursor from
paragraph to paragraph.  This has two benefits:

1) The user's data is protected from program crashes.
2) The user's data is continually, implicitly being saved.  The user is spared from needing to save on a
schedule similar to voting in Chicago (save early, save often).

As I am not planning to work on Baboon anytime soon, I leave it up to the Baboon team to evaluate and implement
the above ideas based on their own merits.

I merely offer these comments based on lots of bad experiences I have had with Microsoft's OLE corrupting my
data files beyond repair.


Regards,

David Orme

--                 "Trying to get Windows to run on the hardware that
David Orme                  Linux typically [flys] on is like pushing
david@coconut-palm-software.com        an elephant through a keyhole"
http://www.coconut-palm-software.com           --Forbes Magazine