Re: [LONG] Roadmap, MC and component model

[Duncan Pierce <cmrdrp soc staffs ac uk>]

Hi Miguel, thanks for taking the time to read my last posting, which
was a bit longer and less structured than intended.

I think it's important to understand my point in going the way I
suggested, because it seems to relate fairly closely to what you are
trying to do with the "Storage" model in the bigger picture of Bonobo
(but I'm happy to be corrected if I'm wrong about this).  I understand
from your roadmap posting that Storage is still unfinished, and I want
to influence your (i.e. everyone's) thinking on this because I think
we can do something that will provide Gnome component-based
applications (and others, too) with a lot of "power" at not much cost
in development complexity or run-time.  If what I'm saying is what
you're already planning then great, tell me how to help out!

On Tue, 9 Mar 1999, Miguel de Icaza wrote:
> 
> Your stuff looks pretty much what a storage provides (In Bonobo
> speak).  My plans are to use the prcs2 code for repositories to
> implement this.

Sounds intriguing.  I had thought a little about using a revision control
abstraction for storing documents (but not PRCS) for two reasons: it is an
obvious candidate for storing "undo" information, and also for allowing
people to merge together asynchronously edited docs.  But I don't
understand why you want to do this at repository (i.e. PRCS) level and not
document/file level (i.e. Xdelta).  Am I missing the point (not having
detailed PRCS knowledge)?

> But I fail to see what is the main use for this in regular
> applications.  Please, also keep in mind that every corba operation
> has a big latency compared to regular file system access.

Yes, I know this.  It depends a bit on what you mean by "regular
applications" and what kind of access you are doing.  I agree that (in
general) file access would work slowly.

> I do not feel very entusiastic about having a new file system
> abstraction, because it does not buy us much.  I think.

I think I gave the wrong impression before, so let me try to explain
again, without any special reference to "files" or "file servers".
When I say "files" in this post I really just mean normal local
stored-on-the-hard-disk files, and I'm not implying any physical
distribution at all, but not ruling it out, either.

I propose a repository of objects, stored in a hierarchical
directory-like fashion.  This repository might be local or remote, and
like any directory service we can navigate through it using a path
consisting of names of directories, until we reach the object we want.
The objects are stateful and their state is persistent like (but not
necessarily the same as) files within a directory structure.  

[The next bit has overlap with what happens in Bonobo.  Where I'm
diverging from the "Bonobo way" I'm not implying any criticism, just
coming at it from the storage/persistence/document activation angle,
which is the bit I'm really interested in.]

This is not limited to document-like things with GUI-based views, but
let's say I've got the path name of a document object.  I ask the
repository to find it for me (by name), and then I ask the object
itself to give me a particular named interface of itself, (like "edit"
or "view" in Bonobo), which it does (if it knows how and I'm allowed).
So I get back this object interface that allows me to talk to a
particular aspect of this persistent object, but if I ask to use the
"edit-object" aspect of the document, I also need to set up a view (in
Document-View speak) of it, so the document also returns to me a hint
about what kind of view object I should instantiate to view the aspect
I've been given.

Let's say that I'm told "text-editor", I have to find and instantiate
an object of my own to fill this role, and point it to the object
aspect.  Remember that this is just filling the View role in
Document-View, and is not actually moving bits of text document round
in memory - it serves only a UI function in this context.  Someone
else can follow the same sequence of actions and get the same document
object with their own view (maybe a totally different type of viewer
to mine), and we are both editing it together.  (As I said before,
this is a pretty weak form of groupware, but in functionality terms
it's free since we already have to have this document-view
distinction in Bonobo, according to the IDL files).

The obvious implementation of all this is, of course, files within a
directory structure.  Every object which can be reached through the
directory hierarchy has a state that is (in our implementation)
persisted into a file.  When the repository is local, and the state of
an object within it is stored using exactly one file, it is a simple
matter to write and read the file directly, so in this (very common)
case there is no CORBA overhead, provided we can negotiate to keep
CORBA out of the picture, or at least only minimally involved.
Moreover, it seems to me realistic, probable and desirable that a
document server should be active in the same filesystem as the
persistent state for it is stored (this is the normal case, local
editing of a file), so unless you want network- or
virtual-filesystem-like functionality, there is no reason to do any
CORBAy things between the document server layer and filesystem storage
layer.

It happens that you can write a very simple "document" server that
serves files, but this is only an application of a larger idea (this
is where the MC bit came into my previous post).  In all, the
navigation process can be made very similar to what happens in MC when
accessing a (virtual) file in a tar file: assigning "translators" (in
the HURD sense) to points in the path in order to change to a
non-standard interpretation of the "object" in question (specifically
here, choosing to interpret the tar file not as a file, but as a
directory tree).  For me, the translation occurs through asking for a
different aspect to the object than normal, and also not knowing what
kind of object you are really talking to.  What MC is doing is to
provide a standardised filesystem-like interface to its "objects".
Where this proposal diverges from that (aside from the mechanism of
implementation) is that here an object can have any interface, it
_might_ be filesystem-/file-like, or it might be the Document object,
reading to participate in a Document-View relationship with a viewer
or editor.  So when I started talking about filesystems right at the
start of my last post, I made a really stupid choice of words.

Ok, so what am I saying about Bonobo here?  I think:

1. The component model should be separate from and built on top of
   this.

2. This should not be specific to component-model or GUI usage.

3. The component model should not be expressed in terms of the
   "load-save file" style, but in terms of persistent objects.

Maybe this is what you're already thinking? - not sure.  Once again,
thanks for your time.

-- Duncan Pierce  (D.R.Pierce@soc.staffs.ac.uk)