[cap-talk] Facet term

[Jed at Webstart]

At 01:11 PM 6/27/2006, Norman Hardy wrote:
>First of all facets are not wrappers. Also
>The various facets to the same object are merely distinct
>capabilities where the that object can tell which facet a messages
>was delivered by.
>
>Your question about emulation is complex and important and inspires
>me to write up some new stuff on my web site.
>It will take a couple of days.
>One conundrum is the meaning of sending a meter key over a
>communications link.
>Probably a bad idea. In effect a meter key is authority to consume
>resources on some particular CPU.
>It is not of much use on another CPU.

I don't understand why not.  Why should it matter what processor
makes the requests?

>It the meter key is eventually returned to where it was issued then
>it is as good as new,
>if some form of indirection elimination is in effect in the
>transmission protocols.

With a mechanism like the DCCS:

http://www.webstart.com/jed/papers/DCCS/

any invocation can only happen on the system that
directly supports the resource that the capability is
a reference to.  In some sense capabilities in their
internal reference form can't literally "escape" the
system (shared memory system, though it could
of course still be a multiprocessor).

In a distributed, 'capability as data' sort of system (e.g.
YURLs, Wideword, Amoeba, NLTSS, etc.) requests on
capabilities can come directly from remote processes
(active objects).

I have to admit I don't understand why it should make
a difference.  Maybe Charlie Landau (who is certainly
familiar with the issue I'm getting at) could comment,
since I expect he's also quite familiar with Keykos and
the mechanisms you refer to (node and domain keys).

<the remainder is for historical reference>

>On Jun 27, 2006, at 12:07 PM, Jed at Webstart wrote:
>
> > Norm,
> >
> > Just a point in passing regarding:
> >
> > At 10:07 PM 6/23/2006, Norman Hardy wrote:
> >> I recall "facet" first in the Joule context, when it was spelled
> >> "Jewel".
> >> See <http://www.agorics.com/Library/joule.html>.
> >> In Keykos two start keys to the same object are two facets to the
> >> same object.
> >> Dean Tribble or Mark Miller probably introduced it.
> >>
> >> I introduced "service key" recently to unify a discussion of keepers.
> >> See <http://www.cap-lore.com/CapTheory/KK/Keeper.html>.
> >> It is a key category for explaining kernel logic.
> >> It was to unify a discussion of keepers.
> >> The kernel's message to the keeper includes the service key to the
> >> kept object so that the keeper can fix the object.
> >> The service key for a meter or segment is the node key.
> >> The service key for a domain is the domain key.
> >> The kernel knows node keys and domain keys when it sees them.
> >
> > Can the node and domain keys still be effectively "emulated"
> > (substituted) by an extension (e.g. remote) key?  If the kernel
> > knows node and domain keys when it sees them, that would
> > seem to suggest that it would know when it received an
> > extension (e.g. emulating a node or domain key) key
> > instead.  In my limited experience (e.g. with RATS) that's
> > an area where care needs to be taken to insure that all
> > the base system capabilities can be emulated/extended
> > (as the file capability was not on RATS).
> >
> > Just thought I'd ask.  Perhaps Charlie knows?
> >
> > --Jed http://www.webstart.com/jed/
> >
> >
> > _______________________________________________
> > cap-talk mailing list
> > cap-talk at mail.eros-os.org
> > http://www.eros-os.org/mailman/listinfo/cap-talk
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk