[Persistence-sig] Is is possible to separate programming API from IDataManager api?

[Jeremy Hylton]

>>>>> "ER" == Ernesto Revilla <aerd@retemail.es> writes:

  ER> Is it possible to separate programming API from IDataManager API
  ER> and define them separate and independently?

I'm not sure what you mean.  The APIs are separate, but any useful
package is going to need to have both APIs.  In other words, we can
makes changes to the APIs independently, but we need to make decisions
about both of them.

  ER> Can there be a mechanism to vote about the API, like a Wiki with
  ER> a voting mechanism (with dead-lines)?

I like the IETF model for Python SIGs: We don't believe in kinds,
presidents, or voting.  We believe in rough consensus and running
code.

  ER> Could we get a level 1 API, without multi-thread issues and
  ER> multiple-save points? (20/80 -> use 20% of resources to solve
  ER> 80% of use cases, leave other 15% for level 2 API).

  ER> Please, just CRUD (Basic Create, Update, Delete). Transactions
  ER> with minimum, i.e. begin, commit and rollback, without nesting.

  ER> Please set minimum of metadata, so the resource manager can
  ER> imagine how to store the data.

I certainly don't think we can ignore threads.  There are lots of
multi-threaded programs and we need some simple way to accomodate
them.  I think the latest ideas that Phillip and I discussed deal with
threads pretty well.  

The API issues for multiple save points also seem pretty
straightforward.  It's a very useful feature, supported by many
databases, so I'd rather not leave it off.

Put another way, I don't think that the difficulties of nested
transactions or multi-threading are preventing us from making
progress.

Jeremy