[cap-talk] How desirable / feasible is a persistent OCAP language?

James A. Donald jamesd at echeque.com
Thu Jul 24 17:34:30 CDT 2008


  James A. Donald:
 > > 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.

ihab.awad at gmail.com:
 > 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.

Durable objects need to be updateable, or need to update
themselves using Bayesian analysis of the evidence.
Doubtless this can be done, but it is not easy.

James A. Donald:
 > > 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.

ihab.awad at gmail.com:
 > 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 decomposable 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.

The registry is dreadful, and etc/config is worse.
Easier than that might well be achievable, but so far,
easier than that is only imagined.  Needs to have the
user interface fully mocked up and prototyped in order
to judge if it actually is easier, then it needs to be
actually written.

Neither the registry nor etc/config have provision to
maintain, or even define, internal consistency.  Worse,
in this era we are primarily concerned with networks,
and atomic update of a distributed system is not
practical.  Even though theoretically possible, it is in
practice too fragile unless the network is tightly
coupled and homogeneous, and gets more fragile as the
distribution gets broader and the network more
heterogeneous, so we have to have arrangements whereby
state in one machine that refers to state in other
machines can tolerate a certain amount of inconsistency,
and will reliably transition to a more consistent state
without anything very bad happening.  Machines have to
represent and handle doubt and uncertainty.

All of which is doable, and doubtless needs to be done,
but has not been done, and it looks to me like a big
scary project.

They say that prediction is hard, especially about the
future, yet I have had remarkable success in making
predictions:  Once again, I predict that this will take
longer and cost more.


More information about the cap-talk mailing list