From: waltrip@capd.jhuapl.edu
Subject: Re: Object Oriented File System: Huh??
Organization: CAPVAX, JHU/APL
Date: Mon, 14 Sep 1992 04:16:26 GMT

In article <1992Sep13.231325.9350@microsoft.com>, edwardj@microsoft.com (Edward Jung) writes:
> Ernest Prabhakar writes:
>>In article <1992Sep4.182618.28508@adobe.com> caro@adobe.com (Perry A. Caro)  
>>writes:
> 
>>> First generation OOFS are bound to underperform mature traditional
>>> filesystems. 
>>
>>Well, yes.  However, ObjectStore (from ODI) whom NeXT has contracted with to  
>>build this sucker bills itself as a 'second-generation OODBMS'.  What does that  
>>mean?  I dunno.  All I know is that their promotional literatures has  
>>'performance' written all over it, so they apparently think their performance  
>>is pretty good.
>>
>>I was curious if the Honorable Elder Statesman Mr. Caro (;-) could evaluate  
>>their claims and let us know whether
>>a) ODI has in fact solved that bottleneck
>>b) ODI's marketing is a bunch of hooery
>>or
>>c) OODB and OOFS are sufficiently different that the two don't tell us anything  
>>about each other.
> 
> I was browsing this newsgroup after a long hiatus from csn (and, no,
> the Microsoft bashing has not subsided, I see), and this topic caught
> my eye. Starting two years ago up until last year, I led an evaluation
> of all the major OODBMS technologies. Microsoft has been working on
> a so-called object-oriented file system for a number of years -- it
> was mentioned at the NT PDC -- and I have a little perspective on
> this problem. I was also the MS rep. to the OMG.
> 
> First of all, ODI is unlike most other OODBs. They are based on a
> very fast page-fault handling mechanism that pages in-memory objects
> into and out of disk on demand. For page-type access to objects,
> and for seamless programming model between app and storage objects,
> this is a very nice mechanism.
> 
> However, many applications need or want non-seamless access, because
> they treat persistent objects quite differently from in-memory ones.
> Access control, concurrency control, sharing, and a number of other
> semantics get in the way of true seamlessness. It is possible to
> make all these uniform between memory and storage (so-called single-
> level store), but it is quite a different way of programming. It also
> has yet to yield high-performance results. That isn't to say it is
> not possible, but only that it has not been done before.
> 
> Some other systems default toward stream-like access, more like a
> traditional file system.
> 
> What is orthogonal to both of these mechanisms, however, is how
> the system deals with features like transaction control, robustness,
> interoperability with stream-based protocols, sharing and concurrency,
> and database features like queries and consistency. ODI is strong
> on the programming model and seamlessness, strong on object fauling
> performance, and weak on feature performance (some other DBs are
> better at other things). Designing an OOFS or OODB depends on what
> you think are the features you need and performance goals to
> optimize. For example, Microsoft spent some time profiling our
> current applications and thinking about what future OO applications
> will be looking like in terms of access to persistent storage
> in order to influence our designs. There is also the matter of what
> the primary application of the new filesystem will be -- new forms
> of information access and organization, consistency, workgroup and
> workflow policy support, programming support, etc., etc.
> 
> Of course there are many more complex issues in this area, 
> including UI and implementation, but I hope this helps.
> 
> Edward Jung, Software Architect, Sr. Program Manager
> Advanced Systems, Microsoft Corporation
> edwardj@microsoft.com
>