Shalabh Chaturvedi wrote:

>I agree with you on most points. In fact I have been motivated by similar
>factors to try and design componentized additions to Quixote. However if
>applications want to be portable across data sources, they have to be
>written to one defined interface and then are limited by the different
>implementations available for that interface. This is still a step up from
>something like Zope, where applications written for ZODB cannot be
>(easily) ported to relational databases.
>
>

I may have gone a little far when I suggested "abstracting away all
persistence details" in my earlier rant. ZODB and any relational
database have almost nothing in common, and abstracting their
differences would be very tough.

>I think that a data persistence interface by itself could be used
>*instead* of components with pre-defined interfaces. For examle, instead
>of having a user management component that implements an interface (i.e.
>an API consisting of a bunch of methods), there could just be a user 'data
>schema' (i.e. consisting of a set of objectclasses each consisting of a
>set of attributes).
>
>Now any application such as an issue tracker uses the standard persistence
>interface to add and read user and group information. When someone wants
>to deploy this application, he simply points it to the correct objectclass
>in his environment, that may be implemented over any data source. Now you
>have a new application working with *existing* data. In fact there might
>be a separate application that adds and deletes users so that function of
>the issue tracker may be turned off by configuration.
>
>
Hm... I was going to argue that an interface is necessary since, at the
least, one needs lookup functions. Having a User object without a
well-known 'UserSource.getUser(userid)' method isn't too helpful. But
'getUser' and the rest of the interface could be derived from the
schema, couldn't it? SQLObject et. al. use this approach, I believe.

>Taking the idea further, the schema doesn't even have to be pre-defined.
>During deployment, the deployer may *create* a new objectclass from
>existing ones simply by configuration (specifying joins, mapping attribute
>names etc.). This new objectclass now exposes the correct schema for the
>new application and they can be tied together.
>
>Sorry for going on and on,
>
I'm eager to listen. ;-)

>but I think the idea I am trying to push is to
>use a data-oriented approach rather than an interface-oriented one. With
>interfaces, you always need a pre-written component that implements the
>correct interface.
>
Yes, though not necessarily implementations. One can create an Interface
class that specifies the required methods and attributes but does not
implement them. Java, Zope3, PyProtocols/PEAK share this notion. Such
Interfaces are declarative in nature, like schemas; not that I'm
equating the two concepts.

In practice, do you conceive the data-oriented approach being sufficient
in cases where the back-end systems are quite dissimilar? For example,
it is not hard to imagine moving user management away from a relational
database toward LDAP. What benefits might be gained from a data-oriented
approach (c.f. an interface-oriented one) in such a case?

I may have misunderstood some of your ideas. I'm left with the notion that

    * a schema implies an interface (with create/retrieve/update/delete
      functions),
    * a schema could be used to generate an implementation of the
      implied interface (!) against a particular persistence system
      (e.g. MySQL),
    * but not all possible implementations of the interface could be
      generated in this way,
    * that applications using the schema are really using the
      implementation, via the interface, not the schema itself,
    * therefore schema are a useful tool for building implementations,
      and implying interfaces,
    * but the interface is the truer decoupling point, since an
      implementation that cannot be derived from the schema could be
      substituted if necessary (as I suspect in the RDBMS/LDAP case, for
      example).

I'll probably regret posting that last bit when I re-read it tonight,
but I have to head home...

I'm eager to hear your thoughts.

-- Graham


-- Graham