[cap-talk] Objects and Facets

[Charles Landau]

At 9:19 AM -0400 8/2/06, Eric Northup wrote:
>On Aug 2, 2006, at 8:23 AM, Neal H. Walfield wrote:
>>  On the Hurd, we have the following: a file consists of its contents
>>  and some meta-data.  When a user calls "open", the file server doesn't
>>  simply return a capability naming this state; it first allocates some
>>  memory to hold, among other things, the position of the cursor in the
>>  file and returns a capability naming that state.  This state is
>>  private to each open.
>>
>>  In the language of capabilities, what would be the file object here?
>>  Is it the shared state and the private state?  (If so, is the shared
>>  state also a separate object from this conglomeration of the shared
>>  state and the private state?)  Is it the private state with the
>>  addition of a capability naming an object encapsulating the shared
>>  state?  In short, what's the right way to talk about these things?
>
>Fair warning: I make no claim that the [following] is the right way to talk
>about these things, it's just the way I think about them.

Here's my thinking:

>It seems to me that, in the design you presented above, there are two
>distinct objects.
>
>The second one, an OpenFileHandle, responds to requests like read(),
>write(), seek(), tell(), close(), etc.  The OpenFileHandle object has
>access to state representing all the bytes of the file, and also the
>per-session state like the cursor position.

I would just call it an OpenFile, since all capabilities are handles.

The state of the OpenFile object is the cursor (and the "other 
things" unnamed above), and a capability to the file.

>The first one responds only (?) to the open() operation, and returns
>OpenFileHandles.  So it might be considered a "factory" object,
>OpenFileHandleFactory.

I would just call it a File. If you were to implement other 
operations such as ReadWithCursor(), you wouldn't want to rename the 
object.

>This object has access to the state representing
>the bytes of the file

The File object doesn't just "have access to", but actually contains, 
the bytes of the file (and the meta-data). That is its state.

>It might be worth considering that *all* the object state described is
>"private", from their clients in the sense that the objects do not share
>it freely with clients.  Instead, the objects expose accessor methods to
>manipulate the state.  The fact that some state is shared between
>different OpenFileHandle instances doesn't make it any less private to
>the clients.

Perhaps I'm misunderstanding the above, but clearly the file data are 
not private. If two processes open a file and one writes, the other 
will read the written data.

>I would not consider them two facets to a single object, because I think
>the factory object is mostly a wrapper (perhaps an EROS Contructor /
>KeyKOS Factory) around a second type of object.  So their top-level
>message processing event loops are different.  I would consider
>ReadOnlyOpenFileHandle / AppendOnlyOpenFileHandle /
>ReadWriteOpenFileHandle to be different facets of the same object.
>
>But the OpenFileHandleFactory and the OpenFileHandle could be
>implemented in a way such that they are two facets to the same event
>loop.  In that case, I would consider them to be different facets.

The description of objects and facets depends on their interfaces and 
is independent of the implementation. The File and the OpenFile have 
different state, so they are different objects.