[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] Capabilities for immutable data
From:       David Barbour <dmbarbour () gmail ! com>
Date:       2011-02-25 10:03:53
Message-ID: AANLkTinYvzwHfB56x9eG8dqCG5M0ZBTqfS0dczgFrTK4 () mail ! gmail ! com
[Download RAW message or body]

On Thu, Feb 24, 2011 at 11:06 PM, Rob Meijer <capibara@xs4all.nl> wrote:
> I'd guess that if you would have said C++, I'd would have had to agree,
> given that C++ has the concept of objects, and at the object granularity a
> process level file handle may be considered ambient. For C however,
> without objects the process IS the level of granularity the code works at,

That characterization doesn't match my experiences. C code does almost
everything with ambient authority: filesystem and database access,
network access, OS integration, memory management, et cetera. There is
a lot of pressure towards monolithic C programs, e.g. to avoid
redundant efforts at serialization and parsing. There are some
frameworks that help keep us to bite-size configurable processes, but
even using those frameworks we are unlikely to see process
abstractions from inside the language. (The code working at the
'process granularity' would more likely be a flow-based language or
shell, rather than C.)

I grant that C++ would lead to a starker contrast with the ambient
authority, but I don't believe that that contrast is logically
relevant.

That aside, I suppose you would rather we focus on your idea:

>
> Unix domain sockets combined with a MAC framework [...]
> I think there is a rough diamond there that a proper abstraction
> may turn into a big shining gem of a C based object capability
> environment.

Flow-based programming (from John Paul Morrison) seems to be one
logical extent in this direction. There are dynamic variations of FBP.

Personally, I think we'd be better off moving in the direction of
YURLs than domain sockets or file handles. That way we are not
specialized to any particular OS, we can run distributed, we can
annotate a growing variety of practical protocols (e.g. streaming,
pubsub, messaging, cacheable query), and we can still support local
system integration.
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]