[cap-talk] How desirable / feasible is a persistent OCAP language?
ihab.awad at gmail.com
ihab.awad at gmail.com
Wed Jul 23 00:54:39 CDT 2008
On Tue, Jul 22, 2008 at 7:04 PM, James A. Donald <jamesd at echeque.com> wrote:
> When some of that information is invalidated by events, while the rest
> remains valuable, what do you do then? Obviously you want to edit that
> information, and no other, ...
> ... but this is not easy, since the human conception what has changed may
> not have any very direct relation to the internals of the object, nor is the
> object likely to be easily editable.
But why? The fact that we have *so far* designed our object encapsulation
with the assumption that objects are throwaway entities does not mean this
is the only way to do things.
> If the primary purpose of one's durable objects is to provide durable
> capabilities, an object on one node is primarily about objects on other
> nodes, ...
... in which case it is highly likely to embody assumptions about other
> nodes, which is highly likely to get one into trouble.
Well, only so many assumptions as the designer of the durable objects has
built into them. Bad design is everywhere, and this is no exception. I've
had to endure many a horrible /etc config file, and those *are* just plain
One way of avoiding this problem is to put all the relevant information in
> an editable file or set of database records, and then recreate the relevant
> objects from the file from time to time, which means the data is durable,
> but is not embodied in durable objects, hence easier to update - the classic
> examples of such storage being the unix configuration file, and the windows
> registry file.
This argument is very deeply intertwined with the technological accidents of
our current state of affairs. A lot of the capability patterns I learn about
are simple -- like, say, a revokable forwarder, or a facet that exposes only
a few of the methods on another object. These objects are just as simple as
anything in /etc or the Windows registry; maybe even drastically simpler.
I can imagine a persistent object store that would contain an
"administration console" where all the objects could be searched for,
queried, edited and otherwise updated. The admin could choose from any of
several simple pre-defined patterns and wire them up. If the admin needed
some more scripting capability, they could just extend one of the objects
with a simple little script where needed. The state of the objects can be
rolled back, and object invocations are logged for later analysis.
This system *is* essentially a DBMS-like entity, just like Oracle or
whatever. Yet it is built around a fundamentally composable and non-foreign
abstraction -- objects and messages. No impedance mismatch: it can be wired
into any modern OO software system with minimal fuss. And it's as easy to
edit and keep track of as the Registry; probably way easier, in fact.
Ihab A.B. Awad, Palo Alto, CA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cap-talk