Hi, On 4/13/07, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
It sounds to me more like the transient space needs its own backing store mechanism. It doesn't make sense for unsaved changes to be sent across the SPI, for the same reason it doesn't make sense to send workspace edits to the subversion repo before an explicit commit.
I fully agree when the SPI is used as a remoting layer, but I don't think it's necessary or even beneficial to have a separate backing store mechanism for the transient space when accessing a local repository. I also believe that the most performance-critical deployments will use either fully local or very low-latency network connections to the repository backend. You wouldn't want your performance-critical CMS application to access the content repository over the Internet. As of now the SPI layer implies making an extra copy of transient changes. It is possible to avoid extra copying of binary (and other) values with the current SPI, but transient spaces with large numbers of nodes and properties still face this problem. I'm wondering if we could modify the SPI somehow to allow the client to only keep track of item identifiers instead of the full transient item states and let the SPI implementation decide whether to use a separate client-side backing store for the item states. BR, Jukka Zitting
