[pypy-svn] rev 1761 - pypy/trunk/doc/funding

[arigo at codespeak.net]

Author: arigo
Date: Sun Oct 12 14:55:42 2003
New Revision: 1761

Modified:
   pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
Log:
More blurb on persistance and transparent distribution.


Modified: pypy/trunk/doc/funding/B6.0_detailed_implementation.txt
==============================================================================
--- pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	(original)
+++ pypy/trunk/doc/funding/B6.0_detailed_implementation.txt	Sun Oct 12 14:55:42 2003
@@ -133,9 +133,11 @@
 
 **Transparent distribution** of objects over a network is another middleware feature that would benefit from being implemented at the language level. This is a vast subject which has been studied extensively. There are several implementations already available in Python, with varying degrees of transparence. None however can be fully transparent by definition of the language itself, which allows introspection -- a program using introspection features could thus defeat the delicate mecanisms introduced by a network distribution library. Moreover, such libraries typically impose additional constrains, e.g. are only able to move objects over a network if they are of a class inheriting from a particular class.
 
-We will study which of these implementations is best suited for being moved into the interpreter itself. So far, a foreseen solution would be to design a proxying Object Space that delegates operations to a remote object server over the network. We will also study approaches enabling transparent distributed execution, i.e. in which the Object Space may decide to send not each operation individually, but instead the whole algorithm's bytecode, when numerous remote objects are involved.
+We will study which of these implementations is best suited for being moved into the interpreter itself. These include transparent interfaces to remote objects (CORBA, Java EJB...), transparent distribution of objects, and transparent distribution of processes themselves. For example, a foreseen solution for the CORBA model would be to design a proxying Object Space that delegates operations to a remote CORBA object server over the network, thus hiding the complexities of the underlying protocols. We will also study approaches enabling transparent distributed execution, i.e. in which the Object Space may decide to move not objects or operations, but instead the whole algorithm's bytecode. This enables real transparent distributed execution with applications like fault tolerance (e.g. perform the computations on two machines and compare the results).
 
-**Persistence** is related to distribution; it is essentially a way to move objects transparently between the persistent storage and the main memory. The same remarks apply, e.g. several implementations exist already (e.g. ZODB) but would benefit from better language integration.
+**Persistence** is related to distribution; it is essentially a way to move objects transparently between the persistent storage and the main memory. This subject has already been studied extensively, and there are several implementations already available.
+
+We are considering at this point ZODB, the Zope Database engine, and PyPerSyst and Prevalence, which are quite complete. Their respective developers have already expressed high interest in PyPy. Indeed, they would benefit from better language integration; they currently put non-natural constrains on the programmer in the form of what he is allowed to do for persistence to actually work transparenty. Typically, it is not possible for a library to detect changes like adding elements to lists, so the list objects cannot be automatically marked as "dirty" (needed to save). This requires language support, and more specifically an extension or proxy Object Space.
 
 
 Language-level extensions