Shalabh Chaturvedi wrote:
>
> Hmm.. I read your points again and this time it sounded more like your and
> my understanding is similar :) Let me say that the interface is indeed the
> *physical* decoupling point. After all, in code, only the interface can be
> a decoupling point.

I agree -- I think we are more in sync than I thought. I was caught up
in the idea that the data-provider interface had to be custom-fitted to
the data model (getUser, getPlant, etc.) but your findXXX() approach
removes that obstacle. Given those "simple" semantics, I see how one
could indeed abstract, for example, a User data source that could be
implemented with SQL, LDAP, ZODB,... It reminds me of both tuple-spaces
and the REST concept: a short list of well-known verbs, plus a long list
of nouns, equals a resilient and extensible interface.

Transactions are something that I didn't see addressed in your document;
and I believe this is a service normally provided by a container (which
you seem to be implementing, whether intentionally or not!).

> All data providers have the same interface - this
> interface is fixed and does not change with the schema. Well, on second
> thought, the attribute names would change but not any method names.

That raises some questions. Would you specify that certain keyword
arguments should (only) accept values of certain types? I'm not sure how
one would handle, for example,

     User.findOne(birthdate='1950.12.12')

unless a standard date-encoding was a given. I imagine that the schema
would include such detail?

Intriguing stuff, Shalabh! I'm especially interested in seeing QLime
when it is available.

I'm going to let all of this simmer for a day or two, and will probably
respond again. With luck there will be an onslaught of commentary from
the quixote-users community in the meantime!

I would be very interested in seeing/writing a proof-of-concept app that
used some of your ideas. An issue tracker, perhaps? ;-)

-- Graham